Is classless worth consideration

[Peter Hansen]

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]

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]

Peter Hansen <[email protected]> wrote in message

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]

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.

 

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

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]

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]

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]

Quoting from a previous post quoting by someone else:

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

 

[Hung Jung Lu]

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

 

[Terry Reedy]

s " <[email protected]> wrote in message

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

In a way, yes. In the old class/instance system, all user-defined classes
were instances of type 'class' and all instances of user-defined classes
were instances (objects) of type 'instance'. So that is what you appear to
be referring to whether you mean to or not. When Python get a
code-breaking overhaul, this now redundant system will be dropped.

Python is currently a language for manipulating typed objects. Changing it
to a languge for manipulating prototyped objects, with types eliminated,
would be a major change. But I currently believe it is possible to do
prototyping within the current system. Several years ago, I posted
(another group, maybe cross-posted here) a prototype Self class (based on
second-hand descriptions of Self, and therefore possibly inadequate) for
doing just that. But I have not yet had reason to go any further with it.

So, for me, the way for someone to promote prototyping in Python, and
serious discussion thereof, would be to write a similar class and then a
neat application that exploits that class.

I'm sorry if this sounds personal;

I am not interested in pseudopersonal 'advice' from someone who knows me
not. I
prefer reading and discussing various Python topics.

Terry J. Reedy

 

[has]

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.

ROTFLMAO! I shall frame and mount this line at once!

has (green with envy...

 

[Hung Jung Lu]

ROTFLMAO! I shall frame and mount this line at once!

Before things get out of hand and be misunderstood again, I need to
make a clarification. I don't make fun at analogies. In fact, anyone
that comes up with analogies deserves commendation. Analogies are
factorization of different experiences, no different from code
factorization that we do in programming.

I was pointing out that unification does not mean elimination. In the
case example, pockets, shoes, food containers are all still there,
even after unification. You still put your soup in your food
container.

If people want to know about prototype-based, Self is probably a good
place to start.

http://research.sun.com/self/language.html

regards,

Hung Jung

 

[Erik Max Francis]

If people want to know about prototype-based, Self is probably a good
place to start.

http://research.sun.com/self/language.html

I'd recommend checking out Io:

http://www.iolanguage.com/