On Sat, Dec 18, 2010 at 4:40 PM, Eike Welk
<eike.welk@gmx.net> wrote:
I would love to see this implemented! Off course I like my syntax better. :-)
well, I have to agree with Terry that your syntax looks like chicken scratches. Terseness is not a synonym for elegant. In this proposal, I'm using a terse syntax in two places where I think a less terse syntax would be too verbose. For references, I used & which mirrors the familiar C reference syntax, and for extra arguments, I used * which mirrors the use of that in function parameter lists. Arguably, I should be using * when the result is a list and ** when the result is a dict, but that's a detail not worth obsessing about at this point, since this is pretty unlikely to get added to the language. :-)
On Saturday 18.12.2010 22:26:05 Bruce Leban wrote:
> Whether or not this is useful at all is a big question, but I think it's at
> least more interesting. This isn't perfect. For example
>
> x matches Foo(a=&alpha, b=&beta)
For this case I prose that the class "Foo" should implement a special function
"__rinit__" that breaks an instance apart, into components that can be
matched. These components should be chosen so that they could be given to
"__init__" as its arguments.
"__rinit__" should return the following objects:
* a tuple of objects, corresponding to the regular arguments of "__init__".
* a tuple of strings that contains the argument names.
* a dict of string:object that represents the keyword only attributes.
This doesn't work. Positional and keyword arguments are not mutually exclusive. Furthermore, it may be a significant amount of work to unconstruct an object just to find out if it has an attribute. And some classes aren't "unconstructable".
A type check would be expressed like this:
x matches Foo(&*_)
That would just be
There's no need to bind the results to something.
> could mean checking x.hasattr('a') but there's no guarantee that Foo(a=1,
> b=2) will produce that result. Maybe that's OK.
>
> Also, any values on the right hand side not marked by & are matched for
> equality, so you could write
>
> x matches (3 * 14 + big_complicated_expression, &y)
It's really neat, but maybe too much visual clutter. It should be discussed if
the following looks better:
x matches (x, y) and x == 3 * 14 + big_complicated_expression
Um, this was a *bad* example, indicating how the feature can be misused. There's no need to "discuss" the alternative you give though. The matches expression could be combined just like any other expression. So you could write:
I'm unsure about it.
> which is pretty ugly. And that suggests:
>
> x matches (f(&y), g(&z))
It can only work with the few functions that are bijective. Many algorithms
destroy information and can therefore not be run backwards.
Again, this was a *bad* example.