Announcement

Collapse
No announcement yet.

What OOP in PB might look like

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

  • What OOP in PB might look like

    hi

    i decided to take my cue from dave navarro's comments at http://www.powerbasic.com/support/pb...ead.php?t=2670
    and donned my oo hat to try to imagine what oo support in pb might
    look like.

    first a little background:

    traditional oo languages like smalltalk implement objects by defineing
    a base class all object derive from. all objects are descended from
    this *mother* object. when you want to create a new object you derive
    from an existing class which is close to the one you want and override
    its methods - you never create an object from scratch. java works
    in much the same way.

    this has definite overhead and that's a no-no for us powerbasic programmers
    since we want fast, tight, lean and mean code.

    the alternative is having multiple inheritance where you can inherit
    from more than one class. there need be no base object that all
    objects are derived from.

    while this approach is more efficient it also creates its own problems
    and the situation can quickly get messy.

    the designer of c++, bjarne stoustrup, recognised this and came up
    with the concept of templates (very similar to ada's generics).

    a template is basically a parametrised type. when you design a template
    you don't specify its type but merely define a holder, or holders
    for that/those types. the compiler substitutes the code at compile
    time depending on how you "instantiate" the template in your code.

    this is a very efficient approach - while i think c++ is a large
    and overly complex language a lot of its principles are sound.

    here's a very basic attempt at describing a template class in pb
    syntax:

    Code:
    'tarray.inc
    
    template tarray( t )
     
        class array
     
            private
                const lsize as long = sizeof( t )
                lnumberofelements as long
            end private 
     
            public
     
                constructor array( byval lelements as long )
                    lnumberofelements = lelements
                    array = new t( lnumberofelements )
                    print "constructor called" 
                end constructor
     
                destructor array( )
                    delete array
                    print "destructor called"
                end destructor
     
                function spaceoccupied() as long
                    function = lsize * lnumberofelements
                end function
     
            end public
     
        end class
     
    end template
    the code above would then be used in the following way:

    Code:
    #include "tarray.inc"
     
    function pbmain() as long
        strarray as tarray( string )
        lngarray as tarray( long )
     
        strarray( 20 ) 'create an array of string with 20 elements
        print strarray.spaceoccupied()
     
        lngarray( 40 ) 'create an array of long with 40 elements
        print lngarray.spaceoccupied()
     
    end function
    at compile time, the compiler would substitute "t" for the type
    passed - note that "t" does not have to be an intrinsic type
    but could also be a user defined type or another class.

    this kind of design would allow pb, imo, to implement oo very
    efficiently. in my view of oo a class is a holder for a set of
    operations on a type. the designer of the class can control the
    interface, what the user can see (encapsulation). two standard
    hooks are defined: the constructor where all the initialization
    takes place and the destructor where clean up happens. cleanup
    happens when the object goes out of scope.

    i know that what i've sketched is very simplistic. hopefully it
    illustrates how i picture objects in a future version of pb.

    cheers

    florent heyworth




    [this message has been edited by florent heyworth (edited september 15, 2000).]

  • #2
    Florent,

    Interesting stab . I commend you for it.

    Have you taken a look at Eiffel? There's some interesting constructs as well, such as:

    1) Complete control of constructor methods
    2) Multiple inheritance (I agree with you, it can get messy, but one can make an argument to at least include it)
    3) Constrained genericity
    4) Pre- and post-conditions, along with invariants
    5) Full control of feature usage (class-based, not keyword-driven via words like PRIVATE, PUBLIC, PROTECTED, etc.)
    6) Agents, or what is usually known as delegates or type-safe function pointers (forthcoming in a new version of Eiffel)

    Not that PB would include these notions in (hopefully) the near future, but IMO they're very powerful features.

    BTW your use of the DESTRUCTOR keyword would fit in quite nicely with a lot of discussions going on in .NET newsgroups over deterministic destruction .

    Regards,

    Jason

    ------------------

    Comment


    • #3
      Hi Jason

      looks like this discussion hasn't had many takers. Thanks for
      your input. I've played around with Eiffel, though I've never
      written a *serious* program using that language.

      The whole "design by contract" paradigm is very interesting - I
      consider Eiffel's pre- and post-conditions one of the great strengths
      of that particular language.

      I am definitely a fan of 'deterministic destruction' as opposed
      to garbage collection schemes more sophisticated than reference counting.

      Of course, deterministic destruction does present a few problems,
      the usual being that if you assign a pointer to an object due
      to go out of scope the destructor should not be called if there are
      some dangling references to the object.

      This kind of problem is not a problem as long as one is prepared
      to control the lifetime of an object through careful coding: ie an
      an object which gets passed around or is referred to in other functions
      in , etc should have a its lifetime explicitly set so that its scope
      remains valid for as long as it's referred to.

      Most compilers implement a simple reference counting scheme - I've seen
      where Microsoft is going with its "Managed C++" and .NET architecture
      GC scheme and I'm not for it.

      Cheers

      Florent


      [This message has been edited by Florent Heyworth (edited September 18, 2000).]

      Comment


      • #4
        Doesn't "RAPIDQ" (a Basic programming language for Windows)
        impliment a form of OOP ?

        It can be found at the Basic Guru web site.

        That programming language has some reals quirks IMO and some bugs
        and is not a real compiler like PB, but it does have some nice
        language constructs which could be added to the PB compiler.



        ------------------
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #5
          I do think RAPID-Q has much going for it and it does offer
          LUNIX and UNIX versions. I would certainly like many of the
          features to be available in Powerbasic such as the ease of use
          of such items as the grid and other common controls. Both GUI
          and Console apps can be developed and the internal objects
          can be extended in the same manner as Florent describes above.

          The program size starts at around 200kb, however, the size
          grows slowly after that. I have enjoyed exploration of the
          platform. It doesn't cost anything except a little time to
          get familiar with the syntax and methods.

          David

          ------------------

          Comment


          • #6
            Florent,

            I would be interested to see what the implications of your OOP design were
            in terms of both operating system architecture and the x86 related
            hardware mnomonics of push / call syntax.

            While I personally am in no rush to implement any more than the bare
            basics of operating system code for reasons of both speed and size, there
            is an enduring interest by many in constructions of this type so it is
            worth asking the question.

            Historical constructions of the type that are done with the x86 push / call
            syntax with parameters pushed onto the stack has convention and size
            efficiency going for it. There is a move in later software to use either
            arrays or structures to pass parameters, especially if there are a large
            number to pass and this is also an efficient method of passing data between
            procedures.

            Now what I am wondering is if there is a way to implement the mechanics of
            modern OOP without blowing out the overhead to run it. Unfortunately most
            of the modern implementations are associated with bloated front end
            generators and this is not in itself a consequence of fundamental OOP,
            just bad association.

            Within the framework of x86 architecture and current 32 bit windows
            design, do you see a way of implementing an efficient form of OOP that
            still delivers in terms of both speed and size as can be done in the
            historical format of push / call syntax that underlies functions/subs etc
            ..

            What I would be interested to see is if this style of construction has
            anything to offer over and above familiarity to programmers who work in
            the OOP model. I had in mind things such as if the use of abstraction gave
            any advantage in term of power, speed or size.

            I am still of the disposition where I can comfortably mess up "well
            behaved" code with such vulgarities as unconditional jumps at a module
            level if I get a size, speed or power advantage from it. What I would like
            to find out is if there is any advantage in OOP style coding at the low
            level grunt end.

            Regards,

            [email protected]

            ------------------
            hutch at movsd dot com
            The MASM Forum

            www.masm32.com

            Comment


            • #7
              Steve--

              Take a look at http://extreme.indiana.edu/~tveldhui...e97/index.html

              Regards
              Peter

              ------------------
              [email protected]
              www.dreammodel.dk

              Comment


              • #8
                Peter,

                Thanks for the URL, its interesting stuff, even though it is comparing a
                very old language concept in Fortran to C++. The article appears to pin
                the hopes of getting C++ up to pace in comparison to Fortran by means of
                better compiler optimisation. The use of LOCAL variable is documented in
                the Intel data and it is a capacity available in most low level complers
                and assemblers.

                The advantage using LOCAL variables is usually that in looped access, they
                are faster but OOP has no advantage here, I regularly use LOCAL variables
                in MASM which is the true opposite end to OOP. I am not of the generation
                of hand optimised Fortran but I know that on any given platform, all
                languages reduce down to their assembler components when compiled so where
                performance is critical, assembler has usually been the solution.

                Now the nature of my questions to Florent were based on his own "hands on"
                knowledge of OOP programming and his direct experience working in
                PowerBASIC to see if there is a way of implementing at least some of the
                OOP concept without suffering a performance penalty from the required
                overhead to get it going.

                PowerBASIC can comfortably be written using the conventional operating
                system architecture and the standard push/call syntax that is below
                functions and subs. What I am interested in is if there is any power,
                speed or size advantage in properly written OOP style constructions. If
                familiarity for programmers who have OOP experience is all that it has
                going for it, then I suggest that the cost is not worth the effort.

                Regards,

                [email protected]

                ------------------
                hutch at movsd dot com
                The MASM Forum

                www.masm32.com

                Comment


                • #9
                  As I have said before PowerBasic already supports OOP
                  With code pointers and data pointers PB is OOP ready
                  You just have to do the work.
                  As Florent has said (sort of) there are two schools of thought for OOP Smalltalk or Simula-67. There are advantages and trade-offs with both schools
                  see:
                  http://www.slip.net/~dekorte/Objecti...mparisons.html

                  Someone could create Objective PB which would be a pre-processor for the superset of commands for OOP.

                  I remember reading a book back in the early 90's that described how NeXT corportation created Objective-C from K&R C.

                  The book is probably out of print, but will be available at your local university library.

                  So, if you want OOP then go ahead. But if you want COM, C#, Java, OCX, or ActiveX support you will have to wait or use another language.

                  Joe Murphy

                  ------------------

                  Comment


                  • #10
                    Most compilers implement a simple reference counting scheme - I've seen
                    where Microsoft is going with its "Managed C++" and .NET architecture
                    GC scheme and I'm not for it.
                    How can you be "not for" it? According to Microsoft, it is your choice,
                    use "unmanaged" code and have both the benefits and the risks or use
                    "managed" code and have a faster development cycle. The flexibility
                    is awesome. What is there to be against?

                    RichB



                    ------------------
                    _____________________________________________________________________________________
                    It's hard when you're up to your armpits in alligators to remember you came here to drain the swamp.
                    President Reagan
                    February 10, 1982

                    Comment


                    • #11
                      Well, I for one am a bit tired of hearing people argue
                      against an OO version of PB. Why? Because nobody has said
                      that an OO version of PB means it must _replace_ the
                      procedureal version. Why couldnt they both exist as seperate
                      compilers?

                      Or even if they did start focussing on OO versions exclusively
                      that wouldnt necessarily mean it would slow down code
                      of users who wanted to stick with just Subs and Functions, nor
                      does it mean it would "bloat" said code.

                      Joseph, as for your suggestion that PB already supports OOP, all i
                      can say is, by your argument, the only thing PB needs at this
                      point is bug fixes since anything else anyone might want
                      can be "simulated" or worked around. You're also being nit picky.
                      You seem to want to make the distinction between Object
                      Oriented Programming versus an Object Oriented Language.
                      Surely you know what people "mean" when they say they want
                      OOP implemented in PB? Why argue over the symantics?

                      And besides that, having to implement objects using the
                      methodology you allude to, really strays far from the
                      spirit of "basic." [hmm.. OO and spirit of basic is
                      probably a contradiction as well] I'll switch to C++ before
                      I ever resort to using a confusing mess of code and data pointers to
                      simulate things like inheritance.

                      All that said, I still like PB despite it not being an OO
                      language. It took me a while to get used to the change, but
                      ive been able to adapt.

                      Steve, I am wondering what improvements to the compiler you
                      would like to see? I havent searched the forumns to see if
                      you've already posted any suggestions, but if you could indulge
                      me by reposting, i'd love to see your ideas. You're a low level
                      asm guy [pigeon hole alert!! ] so I _assumed_ any improvements to PB (not counting any bug
                      fixes) which did not increase code execution speed (and maybe
                      exe/dll size) would be irrelevant to you. You're not one of the
                      DDT guys are ya?

                      Thanks,
                      -Mike


                      ------------------


                      [This message has been edited by Mike Joseph (edited September 19, 2000).]

                      Comment


                      • #12
                        I think I will take a stab at my concept of how OOP could be
                        implimented. Please note, I have little experience with OOP
                        other than using VB 5.0 (which as a bit of OOP in it).

                        The OOP model (whatever is finally chosen) needs to be "very"
                        simple so no bloat is added to the compiler. A poorly
                        designed OOP model for PB would be disastrous to the PB compiler.

                        OOP means "Object Oriented Programming"

                        So what is an Object ?

                        An Object is an advanced UDT (user defined Type)

                        UDTs currently only support Data !

                        PB already has all the necessary data types.

                        Objects must support Data as "properties", but that isn't
                        a big deal, so lets assume that PB is ready to handle OOP
                        data.

                        Objects must also support "methods" which is simply another
                        name for a type of Function or Procedure linked to the Object.

                        PB doesn't currently do this, but does have important features
                        needed to impliment this, such as code pointers.

                        Now lets use what we have and start to build an OOP object !

                        Similiar to the TYPE structure found in Basic, Objects will look
                        similiarly :

                        One note: PB will need to support variable length STRINGs
                        in the Object Type casting. Currently UDTs do not !

                        Code:
                        OBJECT MyObject1
                           PROPERTY MyProp1 as LONG
                           PROPERTY MyProp2 as LONG
                           PROPERTY MyProp3 as string
                           METHOD MyMethod1
                           METHOD MyMethod2
                           METHOD MyMethod3
                        END OBJECT
                        The Methods are simply LONGS which will contain a pointer to
                        procedures with the same name.

                        If the above was a UDT, the metheds would look like this :
                        Code:
                           MyMethod1PTR as Long
                           MyMethod2PTR as Long
                           MyMethod3PTR as Long
                        Then when the UDT is first created, the values would be set by:
                        Code:
                           MyMethod1PTR=CODEPTR(MyMethod1)
                           MyMethod2PTR=CODEPTR(MyMethod2)
                           MyMethod3PTR=CODEPTR(MyMethod3)
                        With Objects you would rather though use the cleaner :
                        Code:
                           METHOD MyMethod1
                           METHOD MyMethod2
                           METHOD MyMethod3
                        and the compiler would handle setting the values to the
                        actual CODEPTR values for procedures with those names.

                        Now, lets look at how the OOP should look again with its methods.
                        Now remember the properties need to have their own Functions to
                        Set and Get them. Two different Functions "must" be assumed for
                        "all" properties. One for each side of the = in expressions.

                        Code:
                        OBJECT MyObject1
                           PROPERTY MyProp1 as LONG
                           PROPERTY MyProp2 as LONG
                           PROPERTY MyProp3 as string
                           METHOD MyMethod1
                           METHOD MyMethod2
                           METHOD MyMethod3
                        END OBJECT
                        
                        METHOD SUB MyObject1.MyMethod1 (Me as MyObject1, OptionalPar1 as Long, OptionalPar2 as Long)
                        
                        END SUB
                        
                        METHOD SUB MyObject1.MyMethod2 (Me as MyObject1, OptionalPar1 as String)  
                        
                        END SUB
                        
                        METHOD SUB MyObject1.MyMethod3 (Me as MyObject1, OptionalPar1 as Long, OptionalPar2 as String)
                        
                        END SUB
                        
                        PROPERTY SETFUNCTION MyObject1.MyProp1(Me as MyObject1, NewValue)
                        Me.MyProp1=NewValue
                        ' then do something
                        END FUNCTION
                        
                        PROPERTY GETFUNCTION MyObject1.MyProp1(Me as MyObject1)
                        FUNCTION=Me.MyProp1
                        END FUNCTION
                        
                        PROPERTY SETFUNCTION MyObject1.MyProp2(Me as MyObject1, NewValue)
                        Me.MyProp2=NewValue
                        ' then do something
                        END FUNCTION
                        
                        PROPERTY GETFUNCTION MyObject1.MyProp2(Me as MyObject1)
                        FUNCTION=Me.MyProp2
                        END FUNCTION
                        
                        PROPERTY SETFUNCTION MyObject1.MyProp3(Me as MyObject1, NewValue)
                        Me.MyProp3=NewValue
                        ' then do something
                        END FUNCTION
                        
                        PROPERTY GETFUNCTION MyObject1.MyProp3(Me as MyObject1)
                        FUNCTION=Me.MyProp3
                        END FUNCTION
                        Then in your code the Object can then be created using :
                        Code:
                        DIM Sample1 as MyObject1
                        The procedures of an Object (Methods) cannot be accessed using
                        the normal calling of procedures. They can only be called using the

                        .Method syntax.


                        ie.
                        Code:
                        DIM Sample1 as MyObject1
                        
                        Sample1.MyMethod1 X&, Y&     ' The object itself is assumed as a parameter
                        Sample1.MyMethod2 D$
                        Sample1.MyMethod3 X&, D$
                        
                        X&=Sample1.MyProp1      ' The GETFUNCTION for the properties are called
                        Y&=Sample1.MyProp2
                        D$=Sample1.MyProp3
                        
                        Sample1.MyProp1=X&      ' The SETFUNCTION for the properties are called
                        Sample1.MyProp2=Y&
                        Sample1.MyProp3=D$
                        Basically, by building upon the current TYPE (UDTs) structure
                        you can create an OBJECT structure.




                        [This message has been edited by Chris Boss (edited September 19, 2000).]
                        Chris Boss
                        Computer Workshop
                        Developer of "EZGUI"
                        http://cwsof.com
                        http://twitter.com/EZGUIProGuy

                        Comment


                        • #13
                          Mike,

                          I have pushed for an architecture based on the reverse of most
                          implementations of OOP style programming that I have seen and its based on
                          the notion that you don't have to copy bad ideas to get improvements. I
                          use PowerBASIC because of what it already does well, the production of
                          high quality binary code with enough power to do most of what I need.

                          To digress some, the notion of an "ideal" language was beaten to death in
                          the 20s & 30s by the linguistic philosophy movement. From Ludwig
                          Wittgenstein's original blueprint in the "Tractatus Logico Philosophicus"
                          came the formula based on Russell & Whitehead's "Principia Mathematica" of
                          a language that would have no ambiguities. It did so by producing a set of
                          rules for what was meaningful discourse and what was not.

                          Russell and Whitehead produced the first coherent system of symbolic logic
                          but it took a young German mathematitian to not only produce the proof for
                          the system but to also determine the boundaries for it. Kurt Godels
                          produced the proof of the boundaries for any axiomatic system and this
                          cashed out in the form that for any given set of axioms, a finite set of
                          true statements can be derived from them yet there are always other true
                          statements within the same category that cannot be derived from that set
                          of axioms.

                          This has interesting implications for a programming language in that a
                          programming language is an axiomatic system that has its basis in formal
                          logic by means of computer hardware doing AND, OR & NOT well. The first
                          set of axioms are determined by hardware, the next subset is determined by
                          the structure of the operating system.

                          Programming languages are the next subsets and it is here where the damage
                          is done. Assembler will allow you to do almost anything that can be done in
                          both the hardware and the operating system if you take long enough. Early
                          compilers were aimed at taking the drudgery out of assemblers and some were
                          close approximations in terms of size and power but far faster to use.

                          The fundamentals of earlier programming languages were based on the capacity
                          to encapsulate blocks of code in forms that we now refer to as Functions and
                          Subs in PowerBASIC. This is well aided by the hardware that has the direct
                          mechanism for doing so in the push/call syntax built into x86 processors.

                          Now my concern is the connection to the fundamental hardware, like any programmer
                          I write and use various forms of encapsulation, function, subs, DLLs etc...
                          What worries me with the push for a different concept is the loss of the connection
                          to the fundamental hardware. OOP languages are concept based rather than hardware
                          based and it is this disconnection that I see as the start of the overhead that
                          is normal to make the concept work.

                          Encapsulation that restricts the design of code is something that I just don't
                          want, method based languages assume that they have got it right and restrict many
                          of the things that you can do at a lower level on the implied assumption that it
                          is unnecessary, unsafe or more probably, display a weakness in the language design.

                          The modern criticism of bloat, poor performance and limitations say that these
                          languages have not got it right and these obvious problems are why I am not all
                          that impressed with the idea of trying to change a language like PowerBASIC to
                          make it as poor as many of the rest.

                          In short, the things that I would like to see in PowerBASIC are the things that
                          will make it more powerful, macros will allow a form of code encapsulation that
                          is normal only in assemblers, static libraries will give the power to build
                          complete high level objects that can be tuned with the normal messaging system
                          in Windows in a very efficient manner in terms of code re-use. I would like to
                          see the COM interface automated in PowerBASIC.

                          Interestingly enough, these are the things that construct OOP and what I push for
                          is the power to design code that can be different, not just use someone elses
                          bad mannered, buggy objects. Now your comments on DDT are interesting, resource
                          templates are a very efficient way to write dialog style code but they are not well
                          suited to complex library design. DDT is a natural way to build much of the interface
                          components if libraries ever become part of PowerBASIC.

                          Objects of the future in PowerBASIC if libraries come to fruition will heavily use
                          DDT as it does not require resource templates.

                          Regards,

                          [email protected]

                          ------------------
                          hutch at movsd dot com
                          The MASM Forum

                          www.masm32.com

                          Comment


                          • #14
                            Steve, thanks for the comments. Just to clarify my DDT comment,
                            i was simply toying with the notion that a low level ASM guy
                            like yourself wouldnt use DDT (or Resource templates for that
                            matter) and that you probably used CreateWindowEx() for all
                            your window creation needs

                            And by extension, that given the option of DDT or
                            <INSERT SUPER COOL FEATURE OF YOUR CHOICE HERE> you would have
                            preferred for the folks at PB to have implemented the latter.
                            Afterall, DDT doesnt exactly make PB "more powerful" just easier
                            to use. (which is what OOP is all about IMO)

                            -Mike


                            ------------------


                            [This message has been edited by Mike Joseph (edited September 19, 2000).]

                            Comment


                            • #15
                              Chris,

                              So what is an Object ?

                              An Object is an advanced UDT (user defined Type)
                              True, but be careful with definitions. An object is an instance of a class. So when you use the word "object" to define a class, it got confusing to me. For example, you have:

                              Code:
                              OBJECT MyObject1   
                                  PROPERTY MyProp1 as LONG   
                                  'etc
                              END OBJECT
                              I would use the word CLASS. Also, feature access needs to be addressed (i.e. who can call the method?). Furthermore, properties are usually read and/or write (which, BTW, I like how .NET handles properties).

                              Regards,

                              Jason

                              ------------------


                              [This message has been edited by Jason Bock (edited September 19, 2000).]

                              Comment


                              • #16
                                To all,

                                I just remembered that there's another tool called RealBASIC. It's a OO-based BASIC language/tool for the Mac:
                                http://www.realsoftware.com/index.html

                                May be interesting to glean some ideas from...

                                Regards,

                                Jason

                                ------------------

                                Comment


                                • #17
                                  Hi Steve

                                  I've been offline for a couple of days so I didn't get a chance
                                  to answer your question, which I understood as being (paraphrasing):
                                  "what would be the impact of introducing OOP in PB be, in terms of
                                  low-level coding, speed and size, based on your experience with OOP
                                  and PB?"

                                  A difficult question...

                                  Low-level coding:
                                  As long as OOP in PB is a hybrid (ie PB does not produce a pure OOP
                                  compiler variation), the ability to fine-tune the code is there, using
                                  inline assembler and/or straight procedural code. I'm assuming that
                                  PB would produce a hybrid compiler.

                                  Speed of execution:
                                  As you know, speed and size is often a tradeoff, one at the expense
                                  of the other. In terms of OOP, speed equivalent to efficient low-level
                                  code can often be achieved if the compiler "expands" the object-oriented
                                  code so that access to member functions is direct as opposed to
                                  indirect via "virtual code tables". It depends a lot on the implementation.

                                  However, having a very efficient library of classes/algorithms to address common
                                  programming problems would definitely help with speed of execution.

                                  Code size:
                                  Again, really depends on implementation. The executable size of code
                                  generated by an OO compiler code to procedural code generated can often
                                  be in favour of OO code if the compiler's smart enough to factor out common
                                  functionality.

                                  I know that this is pretty vague. I've been working on a generic array
                                  OO class in PB to illustrate what kind of optimizations a smart OO
                                  compiler could use to factor out common code/apply speed optimizations.

                                  Since I'm pretty busy right now it'll probably be a few days before
                                  I can post such a beast.

                                  I must say I'm glad that this posting has been generating so much
                                  constructive discussion.

                                  Cheers

                                  Florent



                                  [This message has been edited by Florent Heyworth (edited September 19, 2000).]

                                  Comment


                                  • #18
                                    Steve

                                    I've just re-read your post and I've got a few comments/ideas which
                                    more closely address what you've said than my previous posting:

                                    Within the framework of x86 architecture and current 32 bit windows
                                    design, do you see a way of implementing an efficient form of OOP that
                                    still delivers in terms of both speed and size as can be done in the
                                    historical format of push / call syntax that underlies functions/subs etc
                                    ..

                                    What I would be interested to see is if this style of construction has
                                    anything to offer over and above familiarity to programmers who work in
                                    the OOP model. I had in mind things such as if the use of abstraction gave
                                    any advantage in term of power, speed or size.
                                    A very interesting point - I think you may have guessed at the direction
                                    my simple template posting was going.

                                    What would I expect from OOP in PB?

                                    Power
                                    Speed
                                    Reuse
                                    Encapsulation

                                    I remember that C++ was originally written as a series of pre-processor
                                    macros before being re-designed as a compiler. Macros are all about
                                    "code expansion" and in effect the template concept I posted at the
                                    beginning of this thread is about "template expansion".

                                    Having a compiler implement the template expansion at compile-time
                                    allows for low-level optimizations based on the compiler's knowledge
                                    of the data types and methods of access.

                                    One of the basic ways in which OOP is implemented is by passing
                                    an implicit "pointer to self" pointer to each member function. When
                                    writing procedural code which is library-like (typically provides encapsulation)
                                    that "pointer to self" is passed explicitly.

                                    As such, a low level OO code implementation would have no more
                                    overhead than its procedural equivalent. The real problem, as I see it,
                                    is efficient "dispatching".

                                    If I have a Circle class which inherits from a basic Shape class
                                    I must be able to use the basic functionality of the Shape class
                                    as well as overriding its member functions. If the Shape class has
                                    a Draw method my Circle class must be able to override that
                                    method and provide code which is specific to it.

                                    This is usually achieved through virtual tables which determines
                                    which is the appropriate routine that should be called at runtime.

                                    If we make and stick to the premise that a class is nothing more than a
                                    container we could stick to a template approach where the compiler
                                    would factor out common functionality and duplicate code for the appropriate
                                    type(s) at compile time.

                                    In essence the Circle class would be merged in the Shape class at
                                    compile-time. Code belonging to the Shape class which is not overriden
                                    in the Circle class would not be duplicated.

                                    Using that kind of compile-time expansion would, I feel, give us
                                    the best of both worlds:

                                    efficient re-use and fast code which would not be more bloated than
                                    strictly necessary to implement the missing functionality in the
                                    base template.

                                    Of course, this is not as simple as it sounds. I've got a few ideas
                                    at the back of my head which I'll try to demonstrate as soon as I
                                    can show a very basic prototype of what I'm talking about.

                                    Cheers

                                    Florent




                                    [This message has been edited by Florent Heyworth (edited September 19, 2000).]

                                    Comment


                                    • #19
                                      To Rich Broadway

                                      when I referred to "Managed C++" and the .NET architecture I
                                      was talking about Microsoft's decision to implement garbage
                                      collection instead of using 'deterministic destruction'. My
                                      post basically said that I was not in favour of garbage collection
                                      more sophisticated than reference counting and preferred having
                                      a destructor.

                                      I made no other comment on the possible merits/drawbacks of either
                                      "Managed C++" or the .NET architecture.

                                      Cheers

                                      Florent




                                      [This message has been edited by Florent Heyworth (edited September 19, 2000).]

                                      Comment


                                      • #20
                                        Mike Joseph wrote:
                                        <<Joseph, as for your suggestion that PB already supports OOP, all i can say is, by your argument, the only thing PB needs at this point is bug fixes since anything else anyone might want can be "simulated" or worked around. You're also being nit picky. You seem to want to make the distinction between Object Oriented Programming versus an Object Oriented Language. Surely you know what people "mean" when they say they want OOP implemented in PB? Why argue over the symantics?

                                        I guess that I was not clear at all. What I meant to say that folks who desire OOP to be added to Power Basic base their arguments on the benefits of OOP.

                                        But I believe what they really want it OOP implemented the Microsoft way(COM, OCX, ActiveX, et al).
                                        It is like arguing for the benefits of Relational Database Management Systems and SQL, but only accepting the product if it is 100% compatible with Oracle.
                                        ==================

                                        Mike Joseph wrote:
                                        <<And besides that, having to implement objects using the methodology you allude to, really strays far from the spirit of "basic." [hmm.. OO and spirit of basic is probably a contradiction as well] I'll switch to C++ before I ever resort to using a confusing mess of code and data pointers to simulate things like inheritance.>>

                                        NOT true at all.
                                        All that the programmer using Objective PB would have to do is the typical Object.Method etc. It would be the job of the pre-processor to convert Objective PB source code to pure PB/DLL 6.0 source code and then compile the new code. This is how Objective C operates, and according to Florent it was how C++ was initially developed.

                                        I do not have the free time to write the pre-processor, nor do I have enough capital to finance the effort. But if someone else does a thorough job and offers it for sale at about 75% of the price of PB/DLL then I will buy it.

                                        Joe Murphy

                                        ------------------

                                        Comment

                                        Working...
                                        X