Re: Re: Re: Re[2]: Re: class proposal

Mark Hahn wrote:

> Christian Tismer wrote:

...

>>But why should I ask  trousers.washed?()
> 
> I agree.  I need to go through Prothon and change many things from methods
> into properties.  I just added properties to Prothon last week and I haven't
> gone back and changed them yet.

Whow!

> I will make it file.open() and file.open?.

Why that? You are also asking if ti is closed?,
so why don#t you ask whether it is opened?

For example, I have a single flag in my channel that
means the channel is closed. But as long there are elements
in the channel, I consider it closing. There are the
computed attributes:

chan.closed     # the channel's close() has been called, and
                 # the chanel is empty
chan.closing    # the channel's close() has been called, but
                 # there are still things waiting.
chan.close()    # set the closed internal flag.

>>And would it even exist without the (), probably yes,
>>this would give me the method object. Well, here Python
>>would use the trouser.__class__.washed unbound method.
> 
> Hmm.  It is interesting that you will be able to say file.open to get the
> method, but to get the property you will have to go to great trouble and say
> file.atrs_[$open?] or file.attrs_["open?"].

Yes, I agree this is not so nice.

>>>Python was forced to have file.closed().
>>
>>How that? It was a decision. I would most probably have made
>>it into a computed attribute.
> 
> Even if you did, you couldn't have used file.open, so you would have had to
> use file.closed.  My point is that using the ? gave me the freedom to use
> the word open twice, once as a command and once as a question.

Since I'm used to file.open() as a function since a quarter
century, I would never invent an attribute named close,
but always name it "closed".

...

> I can do the implicit computation and I will do it soon.  My ? still solves
> a naming problem that Python can never solve.

Naming an inquiry attribute is the problem? The English
language is not as rich as more verbose languages,
like in conjugation of "open":

I open the file           ich öffne die Datei
the file is open          die Datei ist offen
is the file open?         ist die Datei offen?
is the file opened?       ist die Datei geöffnet?

Well, there are some options, good enough to use different names.
Are there many verb/attribute clashes in English?

Cases like get() and put() come to mind. Overly stressed in many
years of writing object libraries.
We always avoided to use more than get() and put() actions,
although we could have invented an attribute "put" that says
"this thing has been put".
Here, the native language has its limitations and deficiencies.
For me, this is no reason to enrich it by constructs like
"put?"
Instead, it has a negative effect. The language degenerates even
more by supporting the programmers language sloppiness (SORRY :) ),
so (s)he is enabled to post-enrich poor language by punctuation.

My favor is to put more effort in linguistic design of a
programmer interface. (Where I really dislike outgrowth like
in wxWindows, where they have "centre" instead of "center".
Weeh)

I believe a simple coding-style rule like
isopen, isclosed, isdead
or
opened, closed, killed

is a good alternative than to resurrect semantic readability of
overly over-loaded words by decoration.
And then, a consistent decision about making these into methods
or computed attributes either is a good thing.

not-that-this-is-crucial-at-all-but-a-matter-of-taste -- ly y'rs chris
-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/