Alternative syntax for <|

[Russell Leggett]

On Wed, Nov 16, 2011 at 4:42 AM, Dmitry Soshnikov <
dmitry.soshnikov at gmail.com> wrote:

>  On 16.11.2011 10:27, Russell Leggett wrote:
>
>  Given the recent conversation about class as operator and its likely
> composition with <|, I propose turning the syntax:
>
>     *MemberExpression* <| *ProtoLiteral*
>
> into
>
>      extends *MemberExpression ProtoLiteral*
>
> In the common case of using the class operator, it would read much more
> naturally:
>
>      let Point2d = class extends Point {
>         ...
>     }
>
> or how I propose it, allow using a name, and define it:
>
>      class Point2d extends Point {
>         ...
>     }
>     //which can be grouped as
>     class Point2d (extends Point {
>         ...
>     })
>
> Non-class uses of the syntax might seem a little bit odd
>
>      let specialArray = appBehavior <| [0,1,2,3,4,5]
>     //becomes
>     let specialArray = extends appBehavior [0,1,2,3,4,5]
>
>
>
> Yes, it was mentioned before (especially taking into account that
> `extends' is already reserved).
>

Yes, that's why I was hoping to consolidate - I know extends is what many
want to use with classes, thus why it is reserved.


>
> However, there were arguments about wrong placement of entities regarding
> to `extends' (it turned out that it's like a prototype extends an object,
> but it should be vice-versa).
>
> You put it in the correct place, though as I see we may even eliminate
> assignment here `=' and to make it even more declarative:
>
> let point = {x: 10, y: 20};
>
> // a simple object
> let point3D extends point {
>   z: 30
> }
>
> // a class
> class Point3D extends Point {
>   constructor (x, y, z) { ... }
> }
>
> Since such declarations usually appear exactly in declarative form (sorry
> for tautology), assignment can be omitted.
>

Yes, I would love to see that in the sense that I dislike the alternative.
let Point2d = Point <| {...}, to me, just puts the name too  separate from
the implementation. That is why I'm advocating for the class operator to
have a bit of the function declaration flavor.  However, I wonder if it
starts to become too much additional complication for the language to have
these special forms of let/const. When I see a let, I expect an assignment.


>
> How is it different from Object.create(...)? Actually yes, it's just an
> alternative and in contrast with O.create, I think here we may use not
> descriptors but directly values.
>
> P.S.: in addition, will we introduce another type-tag testing? Or
> `instanceof' and testing constructor property will be enough? I would agree
> and recommend `class' operator as well -- to return, how proposed by Allen,
> the value of the `constructor', actually just a shorthand for not to test
> the `constructor':
>
> if (class(foo) == Foo) // like Python's type
>
> P.S.[2]: and regarding assignment, I think it can be used in
> class-expressions (notice also, unfortunately only hypothetical, since the
> topic became silent, if-expression)
>
> let OperationClass = if (in3dMode) {
>   class extends Point3D {
>     // implementation
>   }
> } else {
>   class extends Point {
>     // ...
>   }
> }
>

if class declarations take expressions as I'm proposing, and if and extends
are just expressions, you could also do

    class OperationClass if (in3dMode) {
      extends Point3D {
        // implementation
      }
    } else {
      extends Point {
        // ...
      }
    }

- Russ


>
> Dmitry.
>
>  but given the overall disapproval of the exact syntax of the <|
> operator, I think its at least a little more obvious what is going on.
>
>  - Russ
>
>
> _______________________________________________
> es-discuss mailing listes-discuss at mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111116/321db57e/attachment.html>