Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Is classless worth consideration

Reply
Thread Tools

Is classless worth consideration

 
 
Peter Hansen
Guest
Posts: n/a
 
      04-30-2004
Hung Jung Lu wrote:

> Peter Hansen <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>>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
 
Reply With Quote
 
 
 
 
has
Guest
Posts: n/a
 
      04-30-2004
Peter Hansen <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> 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.
 
Reply With Quote
 
 
 
 
Dave Brueck
Guest
Posts: n/a
 
      04-30-2004
has wrote:
> Peter Hansen <(E-Mail Removed)> wrote in message

news:<(E-Mail Removed)>...
> > 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


 
Reply With Quote
 
Dave Benjamin
Guest
Posts: n/a
 
      05-01-2004
In article <(E-Mail Removed)>, 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. :
 
Reply With Quote
 
huy
Guest
Posts: n/a
 
      05-01-2004

> 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
 
Reply With Quote
 
has
Guest
Posts: n/a
 
      05-01-2004
"Dave Brueck" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...

> > 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
 
Reply With Quote
 
has
Guest
Posts: n/a
 
      05-01-2004
huy <(E-Mail Removed)> wrote in message news:<409387a1$0$27649$(E-Mail Removed). 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
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      05-01-2004

"Dave Benjamin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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




 
Reply With Quote
 
has
Guest
Posts: n/a
 
      05-02-2004
s " <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...

> 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
 
Reply With Quote
 
Hung Jung Lu
Guest
Posts: n/a
 
      05-02-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) (has) wrote in message news:<(E-Mail Removed). 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"no ip classless" and "ip cef" Paweł Damian Cisco 8 05-25-2009 03:29 PM
IP CLASSLESS not working Max Cisco 13 05-09-2008 09:03 AM
ip classless and auto-summary jh3ang Cisco 3 08-05-2006 03:10 PM
Question about Redistributing Between Classful and Classless Protocols ws00sw@gmail.com Cisco 0 06-28-2005 12:51 PM
[Classless] Just to be sure... Yermat Python 0 04-30-2004 02:11 PM



Advertisments