Is classless worth consideration

D

David MacQuigg

David MacQuigg said:
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
 
E

Erik Max Francis

David said:
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.
 
J

John Roth

David MacQuigg said:
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
 
M

Michael

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?
 
Y

Yermat

Michael said:
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 ? ! ?
.... x = 1
.... def incX(cls, inc):
.... cls.x += inc
.... incX = classmethod(incX)
....3

But is it really usefull ? If you really want something per instance
look at the following code...
.... setattr(inst, attrName, fct.__get__(inst, inst.__class__))
........ pass
........ self.x += inc
....False
 
H

has

David MacQuigg said:
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.
 
M

Michele Simionato

Michael said:
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:
Help on module mymodule:

NAME
mymodule - This a dynamic module

FILE
(built-in)

You can populate the module with setattr or by hand:
1

HTH,
Michele Simionato
 
P

Peter Hansen

has said:
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.
 
A

A. Lloyd Flanagan

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.
 
D

David MacQuigg

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:
... add all common attributes here ...
... 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
 
D

David MacQuigg

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
 
H

has

Peter Hansen said:
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. :)
 
H

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. :)
 
P

Peter Hansen

has said:
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. ;-)
 
H

Hung Jung Lu

Peter Hansen said:
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
 
P

Peter Hansen

Hung said:
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
 
H

has

Peter Hansen said:
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. :(
 
D

Donn Cave

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, (e-mail address removed)
 
H

Hung Jung Lu

Peter Hansen said:
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
 
D

Donn Cave

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, (e-mail address removed)
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top