From: Greg Ewing <greg at cosc.canterbury.ac.nz>
> "Jewett, Jim J" <jim.jewett at eds.com>:
>> With the current syntax, I think the cost is too high
>> for the benefit. It might help to add a keyword, like
>> def foo() wrapped_by [sugary, syntax, list]:
> Some keyword might help, but I don't like that particular
> choice, as it draws too much attention to the mechanism,
I'm certainly not wedded to that specific word; how about
"providing" "also_providing", "including", "extended_by",
or "acting_as"? ("as" is better than nothing, but does
suggest an alias more than a wrapper.)
> I think it ought to be very readable without any keyword,
> provided the names of the wrapper functions are chosen
> appropriately.
By someone with similar background.
> Can you honestly say that, as a Python
> newbie, if you had come across
> def marmalade(self) [classmethod]:
...
> you wouldn't have been able to guess the intent, if not
> the mechanism being used to achieve it?
The problem isn't that *this* function would be too
mysterious; the problem is that it adds mystery to the
*rest* of the language.
I would have assumed that I have to make a (possibly
implicit) similar declaration about every function, and
that the declarations come from a (hopefully) small set,
such as {public, private, static, synchronized, final,
abstract}
The fact that I would have to learn this set (and rules
about which went together) would be a barrier to entry.
The fact that I couldn't quickly find the exhaustive
list (since no such declaration is actually required)
would make me nervous.
If I saw example code not using the [] declaration, I
would assume that the defaults were *mostly* reasonable,
but not always, and it would bother me that I couldn't
find the information about when I needed to override it.
My newbieness is still recent enough that this objection
isn't theoretical; "how long before I can spend more
time coding than searching through the manual" and "how
long before surprises -- even in other people's code --
are at least immediately recognizable instead of deep bugs"
were among the main reasons to choose python over Perl or
Ruby.
> def marmalade(self) [classmethod]:
looks basic enough that I assume I have to understand it
before I can write even a simple program - particularly
since [] characters are pretty common in the rest of the
language.
The huge difference between (legal) definitions
def marmalade(self): [classmethod]
and
def marmalade(self) [classmethod]:
in a language that supposedly uses whitespace instead of
syntax characters would make me assume that the language
really does use all sorts of obsure syntax, but just hides
it in ways that I can't easily recognize.
def marmalade(self) unusual_modifiers[x,y,z]:
at least tells me that this is an unusual case, and that
[x, y, z] has its normal meaning, with any unexpected
behavior attributable to the "unusual_modifiers" that
calls/uses them.
In this case, there would be only one possible unusual
modifier, and it would be listed in the appropriate part
of the documentation, and it would then be clear that I
didn't need to worry about it for most of my own programs.
(Note that "unusual_modifiers" doesn't even have to be
self-documenting to get this benefit, so long as it is
clearly optional and clearly not applicable to *all*
definitions. "extended_format1" would already be useful.)
I also suspect that this won't be the last extension to
definition syntax. Adding a keyword to describe the
extension means that someone who doesn't often use that
particular extension can still skim the code without a
manual handy. Adding new anonymous syntax is already
a bit confusing, and would be unworkable by the fourth
or fifth extension.
-jJ
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4