Announcement

Collapse
No announcement yet.

Discussion why using objects?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    On a purely ideological basis, I just don't like the incongruity of "using classes and objects to encapsulate related data and procedures" with "lets do a bunch of stuff willy-nilly inline."

    Not quite as bad as using inline literals, so only minus three instead of minus five when scoring for artistic presentation.

    But that two points can be the difference between a gold medal and "I, too, showed up."

    MCM

    Leave a comment:


  • Mike Doty
    replied
    "Out of process DLL". Should have said out of process object.
    Yes, the program is an executable, thank you.
    Microsoft Word is used as an example.

    See post #19. Print the topic and enjoy the reading.
    Last edited by Mike Doty; 24 Aug 2008, 11:46 AM.

    Leave a comment:


  • jcfuller
    replied
    MCM
    That's the beauty of the way Bob has designed his objects. You can do it things just about anyway you want. And yes you could do it that way.

    Try the new stuff you'll really like it

    But be careful not to get addicted as I have!!

    James

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Mike Doty View Post
    James,
    You are a man of few words.
    The terminology?
    What!? Have you seen this in action?
    I'm not sure what an out of process dll is? But no out of process exe's .
    ocx ? well it depends on your definition? If it's an in process dll then Yes. If it's a visual ActiveX then as far as I know No.

    James

    Leave a comment:


  • Mike Doty
    replied
    James,
    You are a man of few words.
    The terminology?
    What!? Have you seen this in action?
    Speed? Using direct interace is as fast as calling a SUB or FUNCTION (per docs)
    Why all the negativity about something new?
    Last edited by Mike Doty; 24 Aug 2008, 11:32 AM.

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Mike Doty View Post
    Real men can now use or create OCX's with ease.
    Understatement, in-process or out-of process DLL's.
    Afraid not.

    James

    Leave a comment:


  • Mike Doty
    replied
    Suggestion: Print the help topic to sit-back and enjoy

    Before forming negative opinions read the help, completely!
    In fact, read it until you get it.
    Click Help
    Click PB/Win Contents
    (Under Keyword Quick finder)
    Click Programming Reference
    Click COM programming introduction
    When you see "What is an object, anyway?
    Click Print
    Select "Print the selected heading and all subtopics"
    17 pages if printed on both sides. Enjoy!

    Real men can now use or create OCX's with ease.
    Understatement, in-process or out-of process DLL's.
    Last edited by Mike Doty; 24 Aug 2008, 11:23 AM.

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    'ELSE
    	'Parse the string
    	'oBackUp.Port = VAL(PARSE$(InputStr,1))
                 .......
    No, I have not yet tried any of this stuff, but would it not make sense to have the parsing of the command string ("USEDEFAULTS") itself be a method... to keep all properties and methods of the class within the class code?

    eg.
    Code:
        oBackup.SetParameters (COMMAND$)
    .. or something like that?
    Last edited by Michael Mattias; 24 Aug 2008, 10:34 AM.

    Leave a comment:


  • jcfuller
    replied
    Partial code that will compile using MCM's correct method of getting the parameters from an input file or not.

    James

    Code:
    '=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
    'SED_PBWIN
    '=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
    CLASS cBackUp
    	INSTANCE nPort,OverwriteExistingFile AS LONG
    	INSTANCE Protocol,DestinationHost,File,SourceHost AS STRING
    
    'if this is not to be inherited	use a CLASS METHOD CREATE
    	CLASS METHOD CREATE
    		nPort = 8088
    		Protocol = "http"
    		SourceHost = "www.somehost.com"
    		File = "CurrentTransactions.txt"
    		DestinationHost = "www.otherhost.com"
    		OverwriteExistingFile = -1
    	END METHOD
    	
    	INTERFACE iBackUp : INHERIT IUNKNOWN
    'If this class will be used as a base class use a Default METHOD
    		'METHOD Default()
    			'place contnts of CLASS METHOD CREATE Here
    		'END METHOD
    		METHOD DobackUp
    			?"BackUp in progress"
    		END METHOD
    		PROPERTY SET Port(BYVAL Param AS LONG)
    			nPort = Param
    		END PROPERTY
    		PROPERTY SET Protocol(BYVAL Param AS STRING)
    			Protocol = Param
    		END PROPERTY
    		PROPERTY SET SourceHost(BYVAL Param AS STRING)
    			SourceHost = Param
    		END PROPERTY
    		'add the rest of the properties
    	END INTERFACE
    	
    END CLASS
    
    FUNCTION PBMAIN()
    	LOCAL oBackUp AS iBackUp
    	
    	oBackUp = CLASS "cBackUp"
    	
    	IF ISNOTHING(oBackUp) THEN
    		? "No oBackUp
    		EXIT FUNCTION
    	END IF
    		
    	'Use a ini file for var initialization
    	'Input string 
    	'If InputStr = "USEDEFAULTS"
    		oBackUp.DoBackUp
    	'ELSE
    	'Parse the string
    	'oBackUp.Port = VAL(PARSE$(InputStr,1))
    	'oBackUp.Protocol = PARSE$(InputStr,2)
    	'........
    	
    END FUNCTION

    Leave a comment:


  • Ian Webling
    replied
    As Mr Mattias has said OOP in PB is a tool and we are free to use or not use it. We are also free it use it how we see fit, so one could use:

    ' OOP style, pseudo code, as I haven't got my copy of PB/WIN 9 yet

    Local lResult As Long, Backup As BackupClass

    Backup.Port = 8088
    Backup.Protocol = "http"
    Backup.SourceHost = "www.somehost.com"
    Backup.DestinationHost = "www.otherhost.com"
    Backup.File = "CurrentTransactions.txt"
    Backup.OverwriteExistingFile = %TRUE
    lResult = Backup.DoBackup
    We could also write the DoBackup routine to accept optional parameters, allowing:

    Backup.DoBackup Portno, szProtocol, szSourceUrl, szDestUrl, szBackupFile, _
    bOverwrite)

    or even have a separate function called DoBackWithParameters (usage and requirements obvious).

    Leave a comment:


  • Knuth Konrad
    replied
    Originally posted by Michael Mattias View Post
    Only an amateur would use string literals like that and expect the code to be understandable
    See, this is why an amateur like me enjoys OOP style. It enforce better coding practice on me.

    BTW, I very much like this point in Edwin's first post:

    What i am a bit afraid of is that class are going to be used for any silly functionality.
    An ordinary module can be as equally modular as a class.
    I remember when VB introduced classes and everyone and his dog rewrote each and every little one line helper function as a class.

    Leave a comment:


  • Rodney Hicks
    replied
    I find the way I rewrote the subject code to be reasonably clear
    Actually, more than reasonably.
    A well written, easily understood example of an existing tool, just as Knuth's was of the 'new' tool. And good for comparison, both appreciated by at least one member.

    Leave a comment:


  • Michael Mattias
    replied
    >....that even an amateur could comprehend the concept

    Well, I am perforce biased but I find the way I rewrote the subject code to be reasonably clear.

    But if using "object syntax" forces programmers to cut down on inline literals ("magic numbers"), that would be a Good Thing.


    MCM

    Leave a comment:


  • Edwin Knoppert
    replied
    Originally posted by Kev Peel View Post
    Well I am glad PB finally supports OOP (and creating of COM objects). As a third-party developer, it makes it very easy now to create in PB a library for users of other compilers without having to go through the mess of providing header files and procedural-style sample sets for each compiler.

    All you have to provide is the COM DLL and TLB (plus help files, etc) and that's it. It is truely cross-language. However, that is not to say I would not include a few old-style DLL headers for PB, C and Delphi, but that is all.
    A major benefit.

    Leave a comment:


  • Rodney Hicks
    replied
    Only an amateur
    What I liked about Knuth's post was that even an amateur could comprehend the concept.

    A few posts of that clarity might keep me and others from spinning out on the learning curve.

    Leave a comment:


  • Michael Mattias
    replied
    Only an amateur would use string literals like that and expect the code to be understandable

    Code:
    Portno          = 8088
    szProtocol     = "http"
    szSourceUrl   = "www.somehost.com"
    szDestUrl      = "www.otherhost.com"
    szBackupFile  = "CurrentTransactions.txt"
    bOverwrite    = %TRUE
    lResult = FileBackup(Portno, _ 
                szProtocol, _ 
                szSourceUrl, _
                szDestUrl, _
               szBackupFile, _ 
               bOverwrite)
    MCM
    PS: I wouldn't even use string literals where shown. I'd read those values from configuration file/database/registry.

    Leave a comment:


  • Kev Peel
    replied
    Well I am glad PB finally supports OOP (and creating of COM objects). As a third-party developer, it makes it very easy now to create in PB a library for users of other compilers without having to go through the mess of providing header files and procedural-style sample sets for each compiler.

    All you have to provide is the COM DLL and TLB (plus help files, etc) and that's it. It is truely cross-language. However, that is not to say I would not include a few old-style DLL headers for PB, C and Delphi, but that is all.

    Leave a comment:


  • Knuth Konrad
    replied
    I would guess a majority(?) of posters in this forum are professional programmers who are not in a position to embrace the new Power Objects in their everyday work.
    ... or ...

    I would guess a majority(?) of posters in this forum are professional programmers who already use objects in their everyday work for a long time - just not with PB.


    Procedural and Object Orientated programming are not two opposite poles that don't go together. They interact very well (and very efficently).

    Real Men don't need no stinkin' "classes" to Encapsulate .
    The winning point for me with objects is code readability (which directly translates into code maintenance, which I know you're a big fan of). Consider these two code snippets you might come across into someone's else program:

    Code:
    ' Procedural style
    
    Local lResult As Long
    
    lResult = FileBackup(8088, "http", "www.somehost.com", "www.otherhost.com", "CurrentTransactions.txt", %TRUE)
    You vaguely understand what that line is supposed to do, but for details, you would need to look up the function itself.

    Now, how about this OOP style snippet:
    Code:
    ' OOP style, pseudo code, as I haven't got my copy of PB/WIN 9 yet
    
    Local lResult As Long, Backup As BackupClass
    
    Backup.Port = 8088
    Backup.Protocol = "http"
    Backup.SourceHost = "www.somehost.com"
    Backup.DestinationHost = "www.otherhost.com"
    Backup.File = "CurrentTransactions.txt"
    Backup.OverwriteExistingFile = %TRUE
    lResult = Backup.DoBackup
    Without looking up the procedure's definition and its parameters, the parameters' (properties, in this case) intentions are quite obvious. In the procedural example, is "www.somehost.com" the source or the destination host? And what has the parameter %TRUE for an effect?

    I like this verbose approach. More code to write, but less comments.

    Leave a comment:


  • jcfuller
    replied
    I would guess a majority(?) of posters in this forum are professional programmers who are not in a position to embrace the new Power Objects in their everyday work. I can understand this but personally I just love to program. To create, experiment, and push the envelope. I jump out of bed every morning at 5am with a "what new things will I discover today" anticipation! I have been known to actually giggle when something new I'm working on actually works the way I want. Did I ever mention I suffer from Peter Pan Syndrom? Poo-Poo the Objects all you want, I am still having more fun than I've had in years.

    James

    Leave a comment:


  • Edwin Knoppert
    replied
    I don't think i am a bad programmer but i would like to have had Classes for a few years now.
    I can work it out with odd memory handles but it's expected that this way of programming only takes more time than a good implementation on a compiler level.

    But like i said, i think a lot of nonsense oop based will pass by soon.
    For myself only a few parts are really worth rewritting to a class.

    I forgot oop style programming here.
    Some like to use this kind of syntax, i don't mind that kind of syntax.
    That is not oop, it's oop syntax.

    Leave a comment:

Working...
X