David LeBlanc wrote:
>>In that proposal, static(method) would *not* be a keyword, but would
>>be an identifier (denoting the same thing that staticmethod currently
>>denotes). This syntax nicely extends to
>>
>> def x() [threading.synchronized, xmlrpclib.webmethod]:
>> pass
>
>
> I'm not sure what you're suggesting here semantically...?
That is part of the point: You could add arbitrary annotations
to function definitions, to indicate that they are static methods,
to indicate that multiple calls to them should be synchronized,
or to indicate that the method should be available via SOAP
(the simple object access protocol).
The language would not associate any inherent semantics. Instead,
the identifiers in the square brackets would be callable (or
have some other interface) that modifies the
function-under-construction, to integrate additional aspects.
> It also has the disadvantage of adding a new syntactical construct to the
> language does it not (which seems like more pain than a couple of keywords)?
No. The disadvantage of adding keywords is that it breaks backwards
compatibility: Somebody might be using that identifier already. When it
becomes a keyword, existing code that works now would stop working.
With the extension of sqare brackets after the parameter list, nothing
breaks, as you can't currently put brackets in that place.
> I don't recall any other place in the language that uses [] as a way to
> specify a variable (oops, excepting list comprehensions sort of, and that's
> not quite the same thing IMO), especially in that position in a statement?
> It seems like it would open the door to uses (abuses?) like:
> class foo [abstract]:
> pass
The syntax is inspired by DCOM IDL, and by C#, both allowing to annotate
declarations with square brackets.
> Is there any real difference between what amounts to a reserved constant
> identifier (with semantic meaning rather than value) compared to a keyword
> statement sentinal?
What is a keyword statement sentinal, and what alternatives are you
comparing here?
> Are there any other language-level uses like that
> (reserved constant identifier), or does this introduce something new as
> well?
If you are referring the the
def foo()[static]
proposal: "static" would not be reserved nor constant. Instead, writing
def foo()[bar1, bar2]:
body
would be a short-hand for writing
def foo():
body
foo = bar1(foo)
foo = bar2(foo)
bar1 and bar2 could be arbitrary expressions - nothing reserved at all.
> Speaking of slots, is their primary purpose to have classes whose instances
> are not morphable?
No.
Regards,
Martin
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