Is classless worth consideration

[has]

David MacQuigg <dmq at gain.com> wrote in message news:<g9k090lhocd1nbd7g230br6ooub113hjt6 at 4ax.com>...

> >> 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[s]
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.