Is classless worth consideration

Discussion in 'Python' started by David MacQuigg, Apr 29, 2004.

  1. On 27 Apr 2004 16:34:56 -0700, (has) wrote:

    >David MacQuigg <> wrote in message news:<>...
    >
    >> Example of Simplified Classes ( Prototypes )
    >> ============================================

    >
    >[SNIP]
    >
    >Class-based OOP by any other name. But then, I've pointed this out
    >already. See Emperor, clothes; lack of.
    >
    >Here; while I don't claim them to be paragons of programming, I
    >suggest taking a look at my old AppleScript libraries at
    ><http://applemods.sourceforge.net/>. (Note: scripts are compiled, so
    >you'll need a Mac to view source.) See Types, HTMLTemplate and ASTest
    >for examples of OO programming that isn't class-fixated. Might lend
    >some useful perspective.


    The problem we Python programmers are having is understanding the
    fundamental advantage of eliminating classes and working only with
    instances. The theoretical discussions put me to sleep. I can't see
    the point of the examples above. What we need is a simple use case.

    I've included the ability to clone one instance from another in my
    "Python 3" proposal
    http://ece.arizona.edu/~edatools/Python/PrototypeSyntax.htm
    This will allow the user to completely ignore classes, and just make
    one instance from another, then another, and so on, modifying each
    instance along the way, whenever the urge is felt.

    Here is what I have so far in the Pros and Cons on this feature:

    Pro: Allows "on-the-fly" programming style with no classes.
    Con: Can lead to more undisciplined programming.

    Perhaps you can help us here.

    -- Dave
     
    David MacQuigg, Apr 29, 2004
    #1
    1. Advertising

  2. David MacQuigg wrote:

    > The problem we Python programmers are having is understanding the
    > fundamental advantage of eliminating classes and working only with
    > instances. The theoretical discussions put me to sleep. I can't see
    > the point of the examples above. What we need is a simple use case.


    I certainly don't see the point in having a prototype-based system if
    the declaration for defining a prototype (`proto' in your examples)
    looks very much like the way you build a class. All that seems to
    accomplish is a semantic change of "class" to "proto," which doesn't
    gain anything.

    Compare that to, say, Io -- a prototype-based system -- where there is
    no syntax at all for defining a "class" or "prototype." You simply
    clone and attach messages as you go.

    --
    __ Erik Max Francis && && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
    \__/ Convictions are more dangerous enemies of truth than lies.
    -- Friedrich Nietzsche
     
    Erik Max Francis, Apr 29, 2004
    #2
    1. Advertising

  3. David MacQuigg

    John Roth Guest

    "David MacQuigg" <> wrote in message
    news:...
    > On 27 Apr 2004 16:34:56 -0700, (has) wrote:
    >
    > >David MacQuigg <> wrote in message

    news:<>...
    > >
    > >> Example of Simplified Classes ( Prototypes )
    > >> ============================================

    > >
    > >[SNIP]
    > >
    > >Class-based OOP by any other name. But then, I've pointed this out
    > >already. See Emperor, clothes; lack of.
    > >
    > >Here; while I don't claim them to be paragons of programming, I
    > >suggest taking a look at my old AppleScript libraries at
    > ><http://applemods.sourceforge.net/>. (Note: scripts are compiled, so
    > >you'll need a Mac to view source.) See Types, HTMLTemplate and ASTest
    > >for examples of OO programming that isn't class-fixated. Might lend
    > >some useful perspective.

    >
    > The problem we Python programmers are having is understanding the
    > fundamental advantage of eliminating classes and working only with
    > instances. The theoretical discussions put me to sleep. I can't see
    > the point of the examples above. What we need is a simple use case.
    >
    > I've included the ability to clone one instance from another in my
    > "Python 3" proposal
    > http://ece.arizona.edu/~edatools/Python/PrototypeSyntax.htm
    > This will allow the user to completely ignore classes, and just make
    > one instance from another, then another, and so on, modifying each
    > instance along the way, whenever the urge is felt.
    >
    > Here is what I have so far in the Pros and Cons on this feature:
    >
    > Pro: Allows "on-the-fly" programming style with no classes.
    > Con: Can lead to more undisciplined programming.
    >
    > Perhaps you can help us here.


    So far, I have one use case: text adventure game programming.
    Most of the objects in such games are one-off, and having to
    create a class and an instance for each piece of scenery is more
    than a bit much. This is one of the reasons that standard programming
    languages have never gotten much traction in that domain.

    It's just occured to me that backing into that particular
    issue might work: use class methods and never bother
    with instantiating the classes at all. I'm not sure what
    we'd lose. (possibly descriptors?)

    John Roth


    >
    > -- Dave
    >
     
    John Roth, Apr 29, 2004
    #3
  4. David MacQuigg

    Michael Guest


    >It's just occured to me that backing into that particular
    >issue might work: use class methods and never bother
    >with instantiating the classes at all. I'm not sure what
    >we'd lose. (possibly descriptors?)
    >

    You can already use:

    class test:
    x = 1

    t = test
    print t.x


    Is there any way to to call a class method without making an instance of
    that class? To me that would be useful because you could mimic modules
    without having to create a sepperate file. Or is there already a way to
    do that?
     
    Michael, Apr 29, 2004
    #4
  5. David MacQuigg

    Yermat Guest

    Michael wrote:
    >
    >> It's just occured to me that backing into that particular
    >> issue might work: use class methods and never bother
    >> with instantiating the classes at all. I'm not sure what
    >> we'd lose. (possibly descriptors?)
    >>

    > You can already use:
    >
    > class test:
    > x = 1
    >
    > t = test
    > print t.x
    >
    >
    > Is there any way to to call a class method without making an instance of
    > that class? To me that would be useful because you could mimic modules
    > without having to create a sepperate file. Or is there already a way to
    > do that?
    >


    this way ? ! ?

    >>> class Test(object):

    .... x = 1
    .... def incX(cls, inc):
    .... cls.x += inc
    .... incX = classmethod(incX)
    ....
    >>>
    >>>
    >>> t = Test
    >>> t.x

    1
    >>> t.incX(2)
    >>> t.x

    3

    But is it really usefull ? If you really want something per instance
    look at the following code...

    >>> def attach(inst, fct, attrName):

    .... setattr(inst, attrName, fct.__get__(inst, inst.__class__))
    ....
    >>>
    >>> class Test(object):

    .... pass
    ....
    >>>
    >>> t = Test()
    >>> t.x = 2
    >>>
    >>> def incX(self, inc):

    .... self.x += inc
    ....
    >>>
    >>> attach(t, incX, 'incX')
    >>>
    >>> t.x

    2
    >>> t.incX(3)
    >>> t.x

    5
    >>>
    >>> t1 = Test()
    >>> hasattr(t1, 'x')

    False
    >>> hasattr(t1, 'incX')

    False
     
    Yermat, Apr 29, 2004
    #5
  6. David MacQuigg

    has Guest

    David MacQuigg <> wrote in message news:<>...

    > >> Example of Simplified Classes ( Prototypes )
    > >> ============================================

    > >
    > >[SNIP]
    > >
    > >Class-based OOP by any other name. But then, I've pointed this out
    > >already. See Emperor, clothes; lack of.
    > >
    > >Here; while I don't claim them to be paragons of programming, I
    > >suggest taking a look at my old AppleScript libraries [...] Might lend
    > >some useful perspective.

    >
    > The problem we Python programmers are having is understanding the
    > fundamental advantage of eliminating classes and working only with
    > instances.


    Well, as far as Python itself is concerned, it'd go a long way in
    eliminating the hideously baroque and increasingly brittle OO model it
    currently has. But that's by-the-by; the real problem isn't with
    Python itself but in the "we Python programmers".

    And here one might as well argue the benefits of untyped variables
    with a C/C++/Java-head, or the advantages of a strong functional type
    inference system with a Perl/Python user. If they are curious, open to
    new ideas, keen to explore, challenge and change their existing ones,
    they will seek out and find these questions and answers themselves. If
    they aren't, then no amount of outside argument is ever going to shake
    them from their current position; if anything, it'll only be used to
    strengthen those defences against change.

    So I'm sorry, but the fact you've already mastered Python means that -
    short of investigating the alternatives out of your own desire for
    learning, or being forced into it by unavoidable circumstance - of
    course you can't see what the advantages might be. Having familiarised
    and mastered its complexities, where's the advantage in throwing away
    those skills and knowledge for something unfamiliar? Just as a big cat
    born and raised on a safari park can have no notion of what it's like
    to run the Serengeti. You're so comfortable where you are, why
    would/should you want/need to change?


    > The theoretical discussions put me to sleep. I can't see
    > the point of the examples above. What we need is a simple use case.


    Ah, you mean a clever party trick to dazzle and astound and thereby
    prove its superiority, yes? Sorry, no will do. I mean, sure, yes,
    prototype OO lets you do some very cool and clever things. But then,
    so does something like metaclass programming - and you won't ever find
    me claiming this means MCP is a good thing.

    I'm sorry that my trivial proto-OO stack object example is too
    mundane, but, you know, that's kinda like the _whole_point_. Boring is
    GOOD. Deadly dull is GREAT. Too often, programmers and complexity are
    like crack addicts and cocaine - they just can't help themselves, I
    guess.

    So, let's look at it again:

    begin procedure(initialstate)
    begin object
    _state = initialstate

    begin method(params)
    ...
    end method
    end object
    end procedure

    and compare to:


    begin class
    specialmethod init(initialstate)
    newinstance._state = initialstate
    end specialmethod

    begin method(params)
    ...
    end method
    end class


    In the first, I call the procedure and it executes the statement
    contained within and returns the result.

    In the second, I call the behind-the-scenes class constructor, which
    creates a new instance, calls the special init() method to initialise
    the instance's state, and returns it.

    Now, in both examples the source code itself is approximately the same
    length and density:

    1. Which of these was easier for me to explain?

    2. Which of these was less "magical"? (And what has your Uncle Guido
    taught you about "Explicit [being] better than Implicit" again?)

    3. Which is more linear, spending less time looping in and around
    itself while creating a new object?

    4. Which requires fewer special/unique constructs added to the
    language?

    5. Which maps to more easily and directly from simple procedural
    thinking?

    6. Which should scale further without need for additional support
    features?

    7.. Ah hell, why don't you write some questions for yourself here and
    try answering than make me do all the work?



    > Here is what I have so far in the Pros and Cons on this feature:
    >
    > Pro: Allows "on-the-fly" programming style with no classes.
    > Con: Can lead to more undisciplined programming.
    >
    > Perhaps you can help us here.


    Seriously, I don't think I can help anyone if their idea of an
    argument against Arbitrary Feature X is "Can lead to more
    undisciplined programming"... except by taking away their keyboard,
    along with all electrical appliances, sharp objects, plastic bags and
    anything else they might potentially hurt themselves on if they really
    have a mind [or not] to. But, you know, I simply don't think it's my
    business, or problem, to be saving folks from themselves. Like the old
    adage: Never try to teach a pig a sing. It wastes your time and annoys
    the pig.

    Better for me to say: why not do as I did, and look for the answers
    yourself? If you truly want to find them, you will. If you don't, then
    don't worry, you won't.
     
    has, Apr 29, 2004
    #6
  7. Michael <> wrote in message news:<>...
    > Is there any way to to call a class method without making an instance of
    > that class?


    Yes, with classmethods and staticmethods and more in general with
    custom descriptors.

    > To me that would be useful because you could mimic modules
    > without having to create a sepperate file. Or is there already a way to
    > do that?


    You can dynamically generate a module:

    >>> from types import ModuleType # in Python 2.3
    >>> mymodule=ModuleType("mymodule","This a dynamic module")
    >>> help(mymodule)

    Help on module mymodule:

    NAME
    mymodule - This a dynamic module

    FILE
    (built-in)

    You can populate the module with setattr or by hand:

    >>> mymodule.a=1
    >>> mymodule.a

    1

    HTH,
    Michele Simionato
     
    Michele Simionato, Apr 29, 2004
    #7
  8. David MacQuigg

    Peter Hansen Guest

    has wrote:

    > Well, as far as Python itself is concerned, it'd go a long way in
    > eliminating the hideously baroque and increasingly brittle OO model it


    I find it especially hard to find the enthusiasm to read past
    the highly inflammatory phrase "hideously baroque". I had to
    do a double-take just to confirm that the poster is indeed
    talking about Python.

    If you think it's baroque**, say so. Adding "hideous" just tells us
    you are already highly biased against Python and poisons anything
    else you were about to say...

    -Peter

    ** Please double-check the definition of "baroque" that you are
    using as well. Very little of the meaning that I find at dict.org,
    for example, has ever come to mind while using OO with Python.
    Terms more like "elegant" and "simple" have come to mind, however,
    which is quite at odds with your perception. Strange, that.
     
    Peter Hansen, Apr 29, 2004
    #8
  9. (has) wrote in message news:<>...
    >
    > Well, as far as Python itself is concerned, it'd go a long way in
    > eliminating the hideously baroque and increasingly brittle OO model it
    > currently has. But that's by-the-by; the real problem isn't with
    > Python itself but in the "we Python programmers".
    >


    I wouldn't call it "hideously baroque", myself. Yes, there are some
    details that need to be cleaned up (and when do we get a target date
    for Python 3?). On the other hand, for most programming most of the
    time, it's pretty straightforward.

    Of course, I'm a C++ expert, so my standard of what qualifies as
    "baroque" is probably pretty high. :)

    None of which means I don't think your approach isn't interesting and
    worth pursuing. I look forward to seeing how it goes.
     
    A. Lloyd Flanagan, Apr 29, 2004
    #9
  10. On Wed, 28 Apr 2004 22:48:12 -0400, "John Roth"
    <> wrote:
    >"David MacQuigg" <> wrote in message
    >news:...
    >> The problem we Python programmers are having is understanding the
    >> fundamental advantage of eliminating classes and working only with
    >> instances. The theoretical discussions put me to sleep. I can't see
    >> the point of the examples above. What we need is a simple use case.
    >>
    >> I've included the ability to clone one instance from another in my
    >> "Python 3" proposal
    >> http://ece.arizona.edu/~edatools/Python/PrototypeSyntax.htm
    >> This will allow the user to completely ignore classes, and just make
    >> one instance from another, then another, and so on, modifying each
    >> instance along the way, whenever the urge is felt.
    >>
    >> Here is what I have so far in the Pros and Cons on this feature:
    >>
    >> Pro: Allows "on-the-fly" programming style with no classes.
    >> Con: Can lead to more undisciplined programming.
    >>
    >> Perhaps you can help us here.

    >
    >So far, I have one use case: text adventure game programming.
    >Most of the objects in such games are one-off, and having to
    >create a class and an instance for each piece of scenery is more
    >than a bit much. This is one of the reasons that standard programming
    >languages have never gotten much traction in that domain.
    >
    >It's just occured to me that backing into that particular
    >issue might work: use class methods and never bother
    >with instantiating the classes at all. I'm not sure what
    >we'd lose. (possibly descriptors?)


    So let's see if I can state the problem clearly: We want to be able
    to create many "one-of-a-kind" instances, and the current syntax
    requires an extra statement to instantiate each object from a class.
    We would like to simply clone an existing instance when we need a new
    one, adding whatever changes are needed "on-the-fly".

    I've proposed a syntax to do this, and we are now considering the pros
    and cons of implementing such a syntax. Here is an example of using
    the syntax:

    >>> class S(object): # We need one class to get started.

    ... add all common attributes here ...

    >>> s0 = S() # Empty scene instance.
    >>> s1 = s0():

    ... change attributes for scene1 ...
    >>> s2 = s0():

    ... change attributes for scene2 ...
    >>> s1a = s1( "house", 27, 32 ):

    ... a derivative of scene1 ...
    >>> s1a1 = s1a( "tree", 105, 12 ):

    ... a derivative of scent1a ...

    Cloning an instance is just like instantiating a class, including the
    ability to initialize with arguments.

    Does this provide the basic functionality you need?

    -- Dave
     
    David MacQuigg, Apr 29, 2004
    #10
  11. On Wed, 28 Apr 2004 18:40:07 -0700, Erik Max Francis <>
    wrote:

    >David MacQuigg wrote:
    >
    >> The problem we Python programmers are having is understanding the
    >> fundamental advantage of eliminating classes and working only with
    >> instances. The theoretical discussions put me to sleep. I can't see
    >> the point of the examples above. What we need is a simple use case.

    >
    >I certainly don't see the point in having a prototype-based system if
    >the declaration for defining a prototype (`proto' in your examples)
    >looks very much like the way you build a class. All that seems to
    >accomplish is a semantic change of "class" to "proto," which doesn't
    >gain anything.
    >
    >Compare that to, say, Io -- a prototype-based system -- where there is
    >no syntax at all for defining a "class" or "prototype." You simply
    >clone and attach messages as you go.


    I'm not familiar with Io. The syntax I am proposing will allow
    cloning instances and attaching attributes as you go. What do
    "messages" provide that are lacking in normal attributes?

    -- Dave
     
    David MacQuigg, Apr 29, 2004
    #11
  12. David MacQuigg

    has Guest

    Peter Hansen <> wrote in message news:<>...
    > has wrote:
    >
    > > Well, as far as Python itself is concerned, it'd go a long way in
    > > eliminating the hideously baroque and increasingly brittle OO model it

    >
    > I find it especially hard to find the enthusiasm to read past
    > the highly inflammatory phrase "hideously baroque". I had to
    > do a double-take just to confirm that the poster is indeed
    > talking about Python.


    Compared to C++, I expect it's a real breath of fresh air. But
    compared to how something like Self does OO, it is indeed hideously
    baroque.


    > If you think it's baroque**, say so. Adding "hideous" just tells us
    > you are already highly biased against Python and poisons anything
    > else you were about to say...


    Oh, puh-leez. Now I'll not take you to task for such a dopey comment
    this time around 'cos I'm not a regular here and I'm a right bugger to
    Google for by my initials, so it's hard to figure out exactly who I
    am. But let me remedy this by providing my web address so you can go
    check my credentials:

    http://freespace.virgin.net/hamish.sanderson/

    If you still want to accuse me of such childish nonsense afterwards,
    bring barbeque sauce. :)


    > ** Please double-check the definition of "baroque" that you are
    > using as well.


    "Feature-encrusted; complex; gaudy; verging on excessive."


    > Terms more like "elegant" and "simple" have come to mind, however,
    > which is quite at odds with your perception. Strange, that.


    Yes it is. However, I got my observation skills from several years'
    art school training, so I don't think the fault lies there. I may not
    have the formal CS training and deep programming knowledge and
    experience that many folks here have, but neither am I burdened by the
    religous and political baggage that all too often seems to accompany
    it.

    Oh, and another skill I've learn is saying exactly what I think, and
    being none too shy about how I say it. Just so you know. :)
     
    has, Apr 29, 2004
    #12
  13. David MacQuigg

    has Guest

    (A. Lloyd Flanagan) wrote in message news:<>...

    > > Well, as far as Python itself is concerned, it'd go a long way in
    > > eliminating the hideously baroque and increasingly brittle OO model it
    > > currently has.

    >
    > I wouldn't call it "hideously baroque", myself. Yes, there are some
    > details that need to be cleaned up (and when do we get a target date
    > for Python 3?). On the other hand, for most programming most of the
    > time, it's pretty straightforward.
    >
    > Of course, I'm a C++ expert, so my standard of what qualifies as
    > "baroque" is probably pretty high. :)


    :)

    > None of which means I don't think your approach isn't interesting and
    > worth pursuing. I look forward to seeing how it goes.


    Prothon isn't my baby but Mark Hahn's - see <www.prothon.org>. (FWIW,
    I also consider Prothon's OO programming model unnecessarily complex
    in its current state, but it's still early days so who knows.) As for
    seeing any language projects of my own, well I do have an idea of two
    I'm just getting started on. But I'd not hold my breath if I were you,
    as I'm a rather slow worker. :)
     
    has, Apr 29, 2004
    #13
  14. David MacQuigg

    Peter Hansen Guest

    has wrote:

    > Peter Hansen <> wrote in message news:<>...
    >
    >>has wrote:
    >>>Well, as far as Python itself is concerned, it'd go a long way in
    >>>eliminating the hideously baroque and increasingly brittle OO model it

    >>
    >>I find it especially hard to find the enthusiasm to read past
    >>the highly inflammatory phrase "hideously baroque". I had to
    >>do a double-take just to confirm that the poster is indeed
    >>talking about Python.

    >
    > Compared to C++, I expect it's a real breath of fresh air. But
    > compared to how something like Self does OO, it is indeed hideously
    > baroque.


    Oh, now you're qualifying the statement. In comparison to
    something less baroque, it's baroque. Fair enough...

    But at least you say what you think. That counts for
    something. :)

    -Peter

    P.S. You've got an art background, I've got an engineering
    background, neither of us has a CS background. Maybe that
    ought to tell us how well we're likely to communicate about
    software and we can just stop here. ;-)
     
    Peter Hansen, Apr 30, 2004
    #14
  15. David MacQuigg

    Hung Jung Lu Guest

    Peter Hansen <> wrote in message news:<>...
    > has wrote:
    > > Compared to C++, I expect it's a real breath of fresh air. But
    > > compared to how something like Self does OO, it is indeed hideously
    > > baroque.

    >
    > Oh, now you're qualifying the statement. In comparison to
    > something less baroque, it's baroque. Fair enough...


    Good that things cleared up. I have also pointed out previously that
    Python uses 5 devices where prototype-based needs only one: (a) class,
    (b) instance, (c) module, (d) metaclass, (e) scope. If this is not
    hideously baroque, then, Houston, we've got a problem. If you can
    really think outside the box, you'd pitch in also: (f) aspect.

    regards,

    Hung Jung
     
    Hung Jung Lu, Apr 30, 2004
    #15
  16. David MacQuigg

    Peter Hansen Guest

    Hung Jung Lu wrote:

    > I have also pointed out previously that
    > Python uses 5 devices where prototype-based needs only one: (a) class,
    > (b) instance, (c) module, (d) metaclass, (e) scope. If this is not
    > hideously baroque, then, Houston, we've got a problem. If you can
    > really think outside the box, you'd pitch in also: (f) aspect.


    Well, (c) module is merely a packaging technique, not anything
    to do specifically with OOP, so it shouldn't appear in a list
    of "what do you think makes Python's OO model hideously baroque".

    As for class and instance, unless all other languages that
    have class and instance are also considered baroque, it
    hardly seems fair to separate them.

    Scope doesn't quite seem to fit in this either, but not
    being a theoretician I'll just leave the discussion at
    this point and point out that for the purposes of a *large*
    majority of the people using Python, these issues do not
    arise and Python OO is very much a breath of fresh air
    compared to anything else they've used. Which still makes
    it hard for me to see a claim of "hideous baroqueness" as
    anything other than deliberately inflammatory, but wrong.

    -Peter
     
    Peter Hansen, Apr 30, 2004
    #16
  17. David MacQuigg

    has Guest

    Peter Hansen <> wrote in message news:<>...

    > > Compared to C++, I expect it's a real breath of fresh air. But
    > > compared to how something like Self does OO, it is indeed hideously
    > > baroque.

    >
    > Oh, now you're qualifying the statement. In comparison to
    > something less baroque, it's baroque. Fair enough...


    Merely posting you some meaningful reference points, as I take it by
    your adjectives you're more from the C++ end of the spectrum.


    > But at least you say what you think. That counts for
    > something. :)
    >
    > -Peter
    >
    > P.S. You've got an art background, I've got an engineering
    > background, neither of us has a CS background. Maybe that
    > ought to tell us how well we're likely to communicate about
    > software and we can just stop here. ;-)


    The day that scientists, engineers, programmers and artists start
    talking to one another, instead of constructing vast impenetrable
    fortresses to hide behind, is one I _greatly_ look forward to. Where
    such rampant self-serving cliquery and deeply reactionary
    conservativism sprung from I don't know, but I do wish it'd hurry up
    and bog off again. Poor Leonardo must be spinning in his grave. :(
     
    has, Apr 30, 2004
    #17
  18. David MacQuigg

    Donn Cave Guest

    In article <>,
    (Hung Jung Lu) wrote:
    > Peter Hansen <> wrote in message
    > news:<>...
    > > has wrote:
    > > > Compared to C++, I expect it's a real breath of fresh air. But
    > > > compared to how something like Self does OO, it is indeed hideously
    > > > baroque.

    > >
    > > Oh, now you're qualifying the statement. In comparison to
    > > something less baroque, it's baroque. Fair enough...

    >
    > Good that things cleared up. I have also pointed out previously that
    > Python uses 5 devices where prototype-based needs only one: (a) class,
    > (b) instance, (c) module, (d) metaclass, (e) scope. If this is not
    > hideously baroque, then, Houston, we've got a problem. If you can
    > really think outside the box, you'd pitch in also: (f) aspect.


    As much as I love simplicity, it seems to me you may be
    stretching it here. I would have to agree with Peter Hansen
    that it isn't clear that scope and module would benefit
    from collapse into a single concept along with the rest.

    For that matter it isn't clear that instance and class
    would benefit, but when we get to metaclasses it's harder
    to disagree with you. I think I recall that you have been
    arguing that class and instance naturally give rise to
    metaclass, and that would be a strong argument.

    If it's true - if you really can't write effective,
    maintainable programs in Python without metaclass. To
    me that seems like an absurd proposition, though, if only
    because I'd have no idea how to use metaclass nor why I
    would want to do so. When the idea showed up a few years
    back, everyone chuckled about the `then my head exploded'
    experience of wrestling with metaclasses, and I have been
    assuming that it was a sort of sport accessory for people
    who need a little of that kind of thing now and then. You
    don't think so, it's a basic necessity, programs written
    with just class and instance are liable to be ineffective
    or unmaintainable or something?

    Donn Cave,
     
    Donn Cave, Apr 30, 2004
    #18
  19. David MacQuigg

    Hung Jung Lu Guest

    Peter Hansen <> wrote in message news:<>...
    > Hung Jung Lu wrote:
    > > I have also pointed out previously that
    > > Python uses 5 devices where prototype-based needs only one: (a) class,
    > > (b) instance, (c) module, (d) metaclass, (e) scope. If this is not
    > > hideously baroque, then, Houston, we've got a problem. If you can
    > > really think outside the box, you'd pitch in also: (f) aspect.

    >
    > Well, (c) module is merely a packaging technique, not anything
    > to do specifically with OOP, so it shouldn't appear in a list
    > of "what do you think makes Python's OO model hideously baroque".


    Are you sure about that? Have you seen how people put an class
    instance in sys.modules so they could use it as a module (an old trick
    by now)? Have you seen people asking __call__() to make modules
    callable, and/or property getters/setters for modules? "Merely a
    packaging technique"? Have you seen people using modules as
    singletons? Do you realize that "from ... import ..." is nothing but a
    form of module inheritance? Think again. Let me say it again: think
    outside the box. It's hard to do when you are inside the box. But try.
    Try hard.

    > Scope doesn't quite seem to fit in this either, but not
    > being a theoretician I'll just leave the discussion at
    > this point


    I am sorry, there is no theory to do here. Check out the Io language.

    Code factorization is carried out not when two pieces of code are
    identical, but when they are analogous enough. By tearing things apart
    and claiming that they are different and should not be unified, it
    only goes to show you are still inside a box. All the 6 devices I have
    pointed out can be reduced to one single device: object. Matter of
    fact, many of them are already unified in a prototype-based language
    like Io, no theory there. Why have 6 devices and all kinds of
    redundancies/inconsistencies/hacks, when you can do it all with just
    one? As the other poster said: "hideously baroque" it is.

    regards,

    Hung Jung
     
    Hung Jung Lu, Apr 30, 2004
    #19
  20. David MacQuigg

    Donn Cave Guest

    In a similar vein, I have noticed that clothing often comes
    with pockets, yet this essentially duplicates the functionality
    of shoes, which are also items of clothing that one puts things
    in.

    We can certainly reduce the Baroque complexity of our lifestyle
    if we can eliminate this gratuitous superfluity and rather than
    pockets, simply append shoes to our clothes where needed to
    store a few essentials. Why, you could store soup, all kinds
    of stuff in a shoe that you'd hesitate to put in a pocket.
    Think outside the box!

    Donn Cave,
     
    Donn Cave, Apr 30, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Ternier
    Replies:
    0
    Views:
    345
    Ryan Ternier
    Jan 10, 2006
  2. Yermat

    [Classless] Just to be sure...

    Yermat, Apr 30, 2004, in forum: Python
    Replies:
    0
    Views:
    337
    Yermat
    Apr 30, 2004
  3. steve yee

    about design consideration of strcpy()

    steve yee, May 25, 2006, in forum: C Programming
    Replies:
    13
    Views:
    496
    Charles Richmond
    May 26, 2006
  4. Dave Rose

    classless methods

    Dave Rose, Oct 27, 2006, in forum: Ruby
    Replies:
    12
    Views:
    239
    srdjan.m
    Oct 28, 2006
  5. Robert Dober
    Replies:
    5
    Views:
    130
    Robert Dober
    Aug 4, 2007
Loading...

Share This Page