Is classless worth consideration

[David MacQuigg]

On 27 Apr 2004 16:34:56 -0700, ha*******@virgin.net (has) wrote:

David MacQuigg <dm*@gain.com> wrote in message news:<bn********************************@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 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/Pyt...typeSyntax.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

[Erik Max Francis]

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 && ma*@alcyone.com && 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

[John Roth]

"David MacQuigg" <dm*@gain.com> wrote in message
news:g9********************************@4ax.com...

On 27 Apr 2004 16:34:56 -0700, ha*******@virgin.net (has) wrote:

David MacQuigg <dm*@gain.com> wrote in message news:<bn********************************@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 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/Pyt...typeSyntax.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

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

[Yermat]

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

[has]

David MacQuigg <dm*@gain.com> wrote in message news:<g9********************************@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.

[Michele Simionato]

Michael <mo*****@mlug.missouri.edu> wrote in message news:<ma**************************************@pyt hon.org>...

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

[Peter Hansen]

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.

[A. Lloyd Flanagan]

ha*******@virgin.net (has) wrote in message news:<69*************************@posting.google.c om>...

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.

[David MacQuigg]

On Wed, 28 Apr 2004 22:48:12 -0400, "John Roth"
<ne********@jhrothjr.com> wrote:

"David MacQuigg" <dm*@gain.com> wrote in message
news:g9********************************@4ax.com.. .

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/Pyt...typeSyntax.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]

On Wed, 28 Apr 2004 18:40:07 -0700, Erik Max Francis <ma*@alcyone.com>
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

[has]

Peter Hansen <pe***@engcorp.com> wrote in message news:<Mb********************@powergate.ca>...

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]

al************@comcast.net (A. Lloyd Flanagan) wrote in message news:<e8**************************@posting.google. com>...

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

[Peter Hansen]

has wrote:

Peter Hansen <pe***@engcorp.com> wrote in message news:<Mb********************@powergate.ca>...

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. ;-)

[Hung Jung Lu]

Peter Hansen <pe***@engcorp.com> wrote in message news:<bo********************@powergate.ca>...

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

[Peter Hansen]

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

[has]

Peter Hansen <pe***@engcorp.com> wrote in message news:<bo********************@powergate.ca>...

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. :(

[Donn Cave]

In article <8e**************************@posting.google.com >,
hu********@yahoo.com (Hung Jung Lu) wrote:

Peter Hansen <pe***@engcorp.com> wrote in message
news:<bo********************@powergate.ca>...

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, do**@u.washington.edu

[Hung Jung Lu]

Peter Hansen <pe***@engcorp.com> wrote in message news:<84********************@powergate.ca>...

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

[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, do**@u.washington.edu

[Peter Hansen]

Hung Jung Lu wrote:

Peter Hansen <pe***@engcorp.com> wrote in message news:<84********************@powergate.ca>...

Well, (c) module is merely a packaging technique,

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.

You are being extraordinarily insulting. I was going to
give some other reply, but it's just not worth it.

"Bog off", as 'has' might say.

-Peter

[has]

Peter Hansen <pe***@engcorp.com> wrote in message news:<84********************@powergate.ca>...

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

Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary
duplication of functionality that by rights ought to have been
factored out of the language design early on. So I think it's
reasonable to count them, especially seeing how proto-OO languages
have no problems eliminating them as a distinct type.
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.
Classes and instances are the foundation upon which baroqueness is
subsequently built. Eliminating the former not only gets rid of
another unnecessary type, it also removes the need for a lot of the
shenannigans that its presence encourages.
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.

Oh, I dunno. Let's see now... aside from classes and instances, which
proto-OO has already established is one more type than you need, we
also have (off the top of my head and in no particular order): magic
methods, magic hidden slots, funny privacy, __init__, descriptors,
self as argument, class methods (and variables), making calls to
superclasses, old-style/new-style classes, 'class' vs. 'type'
distinction, coercion, more magic methods (e.g. __slots__), super(),
the usual complaints about inheritance breaking encapsulation and
multiple inheritance gotchas, *anything* beginning with 'meta'... ech,
I could probably go on, but that ought to get you rolling.
You really should go check out Self, NewtonScript, etc. to broaden
your perspective of what OO is, and can be. Don't worry; the fresh
air'll do you good, and I'm sure Python will withstand my mean ol'
attacks upon its fine name in the meantime. :)

[Dave Brueck]

has wrote:

Peter Hansen <pe***@engcorp.com> wrote in message news:<84********************@powergate.ca>...

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

Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary
duplication of functionality that by rights ought to have been
factored out of the language design early on.

No offsense, but this is faulty logic IMO. Just because two concepts can be
unified under the umbrella of another doesn't necessarily mean that elimination
of one or the other is the "right thing to do" if your goal is to make a good
programming language.

Personally I don't really care much about the discussions about purity or
theoretical language simplicity - the fact of the matter is that having modules
and classes is _useful_. If, under the covers, they are (nearly) identical - so
what? In practice it just so happens that they are handy ways to think about
things (one of the things that annoyed me about Java was that it _didn't_ have
modules).

One of the secrets of good language design is not heading too far down the path
of simplicity for the sake of simplicity. Not only are modules a useful
metaphor in big, real programs, they are useful in one-off scripts/apps where
you don't really care about OO, and they're useful when you're teaching
programming to newbies (they are a handy intermediate step in that they show
the basics of separation of functionality, code reuse, etc. without overloading
the student).
So I think it's reasonable to count them, especially seeing how proto-OO languages have no problems eliminating them as a distinct type.

It's certainly a matter of taste - for example, some of the Prothon examples
I've seen so far leave me with the impression that they are work-arounds
showing you how to get by without some language construct you really wish you
had - the I-don't-have-a-chisel-so-this-screwdriver-will-do feeling.

Perhaps proto-OO languages work really well in particular problem niches but
are less well-suited for general purpose work.

-Dave

[Dave Benjamin]

In article <ma**************************************@python.o rg>, Dave Brueck wrote:

Personally I don't really care much about the discussions about purity or
theoretical language simplicity - the fact of the matter is that having modules
and classes is _useful_. If, under the covers, they are (nearly) identical - so
what? In practice it just so happens that they are handy ways to think about
things (one of the things that annoyed me about Java was that it _didn't_ have
modules).

I completely agree with you. I've done a fair amount of both Java and Python
programming, and I have to say I really appreciate Python's module system,
and I always feel like I'm putting a round peg in a square hole when I use
Java's inner classes as a namespacing mechanism. I think Python gets it
right in this respect.

PHP and JavaScript both try to blur the distinction between object and
dictionary. The result is that you can't tell a key from an attribute, and
this can sometimes be problematic. PHP goes a step further and removes the
distinction between array and dictionary. Perhaps this is easier for people
to learn, since they can master one concept and apply it everywhere, but I
much prefer having arrays, dictionaries, and objects as separate concepts
with their own protocols. I like having classes and modules for the same
reasons.

Sometimes, it's nice to treat different things as if they were the same.
Other times, it's nicer to treat different things as being different.
I like a language that gives me a choice in the matter.

--
..:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
: please talk to your son or daughter about parametric polymorphism. :

[huy]

Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary
duplication of functionality that by rights ought to have been
factored out of the language design early on. So I think it's
reasonable to count them, especially seeing how proto-OO languages
have no problems eliminating them as a distinct type.

So were does the actual *file* that the source code sits in fit in this
classification of yours ?

Huy

[has]

"Dave Brueck" <da**@pythonapocrypha.com> wrote in message news:<ma**************************************@pyt hon.org>...

Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary
duplication of functionality that by rights ought to have been
factored out of the language design early on.

No offsense, but this is faulty logic IMO. Just because two concepts can be
unified under the umbrella of another doesn't necessarily mean that elimination
of one or the other is the "right thing to do" if your goal is to make a good
programming language.

None taken, but I think you've misinterpreted what I've said. I've
never said users should be deprived of functionality (i.e. support for
modular construction and object-oriented programming), only that
there's much simpler, more elegant ways to provide it.

HTH

[has]

huy <ny*****@swiftdsl.com.au> wrote in message news:<40***********************@news.syd.swiftdsl. com.au>...

So were does the actual *file* that the source code sits in fit in this
classification of yours ?

In AppleScript - which I'm using both because I know it well and
because, despite its many other flaws, it does this particular stuff
fairly well - a file represents a script object, just like it
represents a module object in Python. Essentially just a portable
namespace. The difference, of course, is that AppleScript's script
objects aren't limited to _only_ being used as modules. Which means,
for example, you can load one script into the other and use the loaded
script either as a module or as a clonable prototype in OOP.

Other points of interest regarding the model AS uses...

Note that there are two file types used in AS: *.applescript, which is
the script in source code form, and *.scpt, which is the script in a
bytecode-compiled, persistent form (an idea it probably got from
Smalltalk). Unlike .pyc files, however, which are only intended for
execution, .scpt files are also intended to be opened, edited, and
otherwise used and abused by their users, and are the form most
scripts are stored in. The AS runtime simply provides complementary
compile() and decompile() routines for editing tools to call, unlike
most other scripting languages which tend only to provide the former.

Of course, this combination of 'one-size-fits-all' generic script
object and highly pervasive object persistence as standard means you
can easily go the other direction too, storing script objects to file
for use as, say, modules themselves. My HTMLTemplate/AppleScript
library does this, for example; template compilation takes several
seconds there (AS sucks for speed), so I simply added code to the base
'Template' node that makes it compatible with my library Loader
system, and now you can compile an HTML template into a custom AS
object model, store it to disk as a module (either as a component to a
larger program or a standalone library in the standard library system
I've set up), then load it up into another script any time you want to
run off a few webpages.
BTW, if anyone with a Mac wants to check it out, all my libraries and
the library Loader system are under new management at
applemods.sourceforge.net. Mind that it's not hugely powerful or
sophisticated stuff compared to what other languages offer, but that
was by design (i.e. AS users have modest needs) not due to language
limitations. What is of note is just how very few language features I
needed to set this system up. I still had to learn all the theory
behind modular and OO systems to design it, of course, but very little
language-specific knowledge was needed to put that into effect.

Which I suppose is really my point: I'd rather fill my head with
valuable knowledge of how to design software systems, than clog it up
with lots of fiddly little implementation-specific details and trivia.
The amount of complexity my mind can manage is pretty limited to most
of yours, so I like to get best bang for my buck I can. :)

HTH

[Terry Reedy]

"Dave Benjamin" <ra***@lackingtalent.com> wrote in message
news:slrnc96kat.20s.ra***@lackingtalent.com...

PHP and JavaScript both try to blur the distinction between object and
dictionary. The result is that you can't tell a key from an attribute, and this can sometimes be problematic. PHP goes a step further and removes the distinction between array and dictionary. Perhaps this is easier for people to learn, since they can master one concept and apply it everywhere, but I much prefer having arrays, dictionaries, and objects as separate concepts
with their own protocols. I like having classes and modules for the same
reasons.
In thinking about dictionaries versus modules (and classes/instances), I
come up with two reasons to have both.

1. A dictionary is a generic association mechanism, with the key being any
hashable object. A module is a association mechanism specialized for the
important and common special case of keys that are name strings, and which
therefore can be written in code without quotes.

2. A module, because of its specialization, has a more graceful syntax for
accessing objects bound to a name known at the time of coding (and
compilation): mod.name versus dic['name']. A dictionary, because of its
generalization, has a more graceful syntax for accessing objects bound to a
(name) key that is only accessible indirectly, at runtime, via a name bound
to the (name) key: dic[namename] versus getattr(mod, namename) (or
hasattr() or setattr()). (For multiple indirect accesses, one can avoid
hasattr, etc by doing modic = mod.__dict__; modic[namename]; ...)

One could propose to combine the syntaxes by allowing dict.name instead of
dic['name'], but this conflicts with the fact the dicts have several
instance methods, and that dicts therefore need an attribute namespace in
addition to and separate from the association they represent.

Allowing mod[namename] as a substitute for hasattr(mod, namename) might be
more feasible (by giving the module type object __xxxitem__ methods), but I
can see objections. One-way unification and indexing restricted to
namestrings both could be confusing. It would also make it easier to write
syntacitically valid but sematically invalid code, whereas the xxxattr
names remind that the access key must be a valid attribute name.

Quoting from a previous post quoting by someone else: Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary

I don't see this. 'Class instance' is an abstract concept, not a
particular object. A particular module *is* an instance of the module
typeclass, so of course modules are like 'class instances': they are a
particular type of class (type) instance. Or, if you will, instances of a
particular classtype. In other words, module and modules are part of the
current typeclass and instance system, not a disposable alternative.
(Classic classes are duplicative and are only kept for back-compatibility,
so I ignore them in discussions like this.)

The particular features of the module type are dual. First, it has a
specialized __init__ method that initializes instances from a file rather
than a set of arguments. Second, while it does have the standard minimal
set of special attributes (__doc__, etc) it does not have any attributes
intended for post-initialization access via the instances. Therefore, we
are free to give module instances any attributes we want. This freedom is
what makes them usable as generic name capsules. (Modules do have
individual __init__-set __name__, __file__, and __doc__ attributes, but
these can usually also be overriden also without problem.)

Terry J. Reedy

[has]

s " <tj*****@udel.edu> wrote in message news:<ma**************************************@pyt hon.org>...

Quoting from a previous post quoting by someone else:

Modules are an encapsulation mechanism, just like class instances, so
I'd say the large and obvious overlap counts as unnecessary

I don't see this. 'Class instance' is an abstract concept, not a
particular object.

Please forgive my linguistic sloppies. How about if I say 'an object
of type "instance"'; does that sound clearer?

Regarding the remainder of your post, your argument seems to be that
Python has got all this stuff [that you describe], therefore all this
stuff is needed. Have you tried the sorts of systems I've been
describing for comparison? Because I've worked with both types of
system, so what I describe is anything but fuzzy theorising: these
systems already exist and there's nothing to stop anyone else from
trying them out themselves _before_ trying to critique my arguments.

So I may I respectfully suggest that yourself and others do just this.
Because then you can argue from a position of strength, having weighed
the pros and cons of both approaches and formulated your arguments
based on that, rather than out of some religious obligation to defend
the orthodoxy from any kind of perceived attack, regardless of whether
or not you even understand what this "attack" actually is. Which is
what these and other arguments, for all their seeming depth, really
boil down to in the end.

I'm sorry if this sounds personal; it isn't really. As an outsider
who's spent years looking in, I've had plenty of time to observe the
best and worst of programming culture in action, and it's the subtle*
but strong undercurrent of blind reactionary conservatism that runs
through much of it that I find most frustrating.

I'm genuinely happy to see my arguments taken apart by folk who
understand them better than me. Many are naive and simplistic and
others are completely wrong; I honestly look forward to having my
preconceptions challenged and my prejudices shattered. It's the
feeling I sometimes get that I'm being rebuffed merely for questioning
the religious orthodoxy; that my position is percieved as a threat
because I won't meekly accept everything I'm told as an obvious truth.
This is what I'm unhappy about.

So please, give me confidence that I'm being taken apart by an expert
who wants to set me right, not by some frightened partisan who only
wants to defend their faith. Impress me. Make me admire your
arguments. Give me something to _really_ think about. I honestly don't
think it's too much to ask.

Regards,

has

--

* slashdot excepted ;)

[Hung Jung Lu]

ha*******@virgin.net (has) wrote in message news:<69**************************@posting.google. com>...

these systems already exist and there's nothing to stop anyone else
from trying them out themselves _before_ trying to critique my
arguments.

That is the whole point. This is not like choosing a government where
once you are done, there is no point of return until years later. Why
don't people just try out?

When one has not even tried, and starts to make criticisms like
"unification means elimination, I will have to use my shoes to store
my soup", it brings nothing but regrets. Ignorance can always be made
temporary, regrets, on the other hand, last a lifetime.

Making criticisms on something that one (a) has never tried, (b) will
never try, is out of the realm of software engineering, even more so
when the downloads are free of charge. I am not sure what these
criticisms show: about a system, or about the persons making the
criticisms?

regards,

Hung Jung