Deprecate Object.:; add ：, ¦ and ⫶

[catb0t]

Deprecate the : (colon) method from Object.

Starting with Sidef v4.0 it will be removed
from Object entirely, and only be used to
create Complex and standard named param-
eter syntax for Blocks (when its LHS is
a bareword).

The utility of : has been bisected into the ：
(fat/fullwidth colon; more easily written
¦) and ⫶ (triple colon).

: as a Pair constructor remains for now, but
code using it should be updated to use the
new methods.

• Object.：, the fullwidth colon U+FF1A:
  force creation of a Pair from self and the first
  argument.

• Object.¦, the broken bar U+A6: alias for ：
  with a shorter hex value to type when using
  Unicode input methods.

• ⫶, the triple-colon operator U+2AF6:
  force creation of a NamedParam with the object
  on its LHS as the name.

  Whereas the normal NamedParam colon operator
  a: val expects a bareword on its LHS,
  the triple-colon evaluates its left hand side
  and therefore allows any value from a names
  or expressions as the name in a NamedParam.

  Previously, it wasn't possible to generate
  NamedParams without eval because of the
  bareword restriction.

[trizen]

Looks good. In addition, I suggest removing the : (colon) Object method, and leaving only ： (fullwidth colon) for creating a Pair object.

Another thing may be to make NamedParam available as a class name (maybe with a better name?), which would allow constructing named-parameters as NamedParam(name, value) and also allowing checking which objects are named-parameter objects (obj.kind_of(NamedParam)).

[catb0t]

Okay, I assumed you wouldn't be interested in a backwards in-compatible change like that, but I'm all for it!

Another thing may be to make NamedParam available as a class name

Yeah, I tried adding it to the parser and deparser but I couldn't get it working. Maybe I'll try again...

[trizen]

Thinking a bit more about this, I'm considering removing the Pair class altogether, and defining the : (colon) method in the String class, returning a NamedParam object (since only strings make sense for the name of a parameter, there is no need to define it in the Object class).

[catb0t]

Moving : colon to String doesn't sound like a bad idea, other than being a huge breaking change.

Personally I get a lot of use out of Pairs and I don't want them to disappear (please :) ).

Plus, there is one big benefit to using ： for Pair: Now you can write :a：:b or 200：:a without confusing the parser into thinking you mean the variable a::b.

Do you intend to keep the 1:2syntax for Complex? I think that's actually a good feature of the syntax, when you can be sure it will produce a Complex... maybe it should be changed to a different fancy operator?

[trizen]

Ok. Let's save the breaking change for Sidef v4.00 then, when lots of code is going break then anyway, as I intend to fix #79 before v4.00 comes out, which requires reimplementing the classes in a better way.

In general, when something is objectively bad and needs to go away or get reimplemented, breaking the backwards-compatibility is acceptable.

The reasons why I think the Pair class needs to go away (in favor of the Array class), are:

• nil : "foo" fails to work, while [nil, "foo"] works
• when three or more values are suddenly needed, you have to use an array
• [x, y] is easy enough to write (while being general for any numbers of values)

Maybe adding the .second method in the Array class may help a bit with the breaking-change.

Do you intend to keep the 1:2 syntax for Complex?

Yes, this is useful sometimes.

[catb0t]

Ok, : is still in Object but maybe the deparser could generate a deprecation warning until v4. I agree about Pair, Array is general enough with a second etc method.

Also, even though ：U+FF1A looks nice it can be long to type, so the ¦ U+A6 is another name for it.