3 ms·

http://nitlanguage.org/manual/genericity/ http://nitlanguage.org/manual/genericity/ > Unlike many object-oriented languages, generic classes in Nit yield a kin

by Tobu 12y ago

http://nitlanguage.org/manual/genericity/ http://nitlanguage.org/manual/genericity/ > Unlike many object-oriented languages, generic classes in Nit yield a kind of sub-typing. For example, Pair[Int] is a subtype of Pair[Object]. Sounds completely broken. What if Pair[E] is contravariant on E? class Pair[E] fun contains(E): Bool fun clamp(E): Bool end > http://nitlanguage.org/refinement/ http://nitlanguage.org/refinement/ (redefining any method) That's spooky action at a distance. It breaks modularity, could cause packaging hell.

klibertp 12y ago
Variance: I suspect it's a subject to similar restrictions as in Haxe: http://haxe.org/manual/type-system-variance.html http://haxe.org/manual/type-system-variance.html > That's spooky action at a distance. It breaks modularity, could cause packaging hell. Swift, Ruby, Nimrod and Smalltalk are a few languages - out of many, many more - which disagree with you here.
- Tobu 12y ago
  Nope. In is_subtype: > # If `sub` is a formal type, then it is accepted if its bound is accepted https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d0d9ad0d29b51337/src/model/model.nit#L695 https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d... Ruby is dynamic and the interpreter is feature-rich. People are just exercising self-discipline. Nit intends to be “a robust statically typed programming language” which is very different. Also, could you point me to the Nim feature? All I see is overloading.
  - klibertp 12y ago
    > Nope. In is_subtype [...] Oh, ok. So it does look a bit broken then :) > Also, could you point me to the Nim feature? That follows from the fact that `something.method()` is just a syntactic sugar for `method(something)` and that you can write methods for any type anywhere. The example I specifically had in mind was strutils module, which extends a string type with many useful methods. Now that I think about it I'm not sure how Nim would handle two methods of the same name for the same type defined in different places. I think it would refuse to compile such code? But that's a guess only, I'd need to check. EDIT: oh, and I see you complained about redefinition specifically, not about the ability to extend classes in general. Sorry, I somehow missed it.
riffraff 12y ago
IIUC refinements are module-local so they are modular and don't break anything.
- Tobu 12y ago
  module-local as in, creating a new type that can't be exchanged with the outside? Or converting the value's type on the fly when it gets passed somewhere else? I doubt either would be very usable. Edit: the page refers to open classes, and I think the idea is that you can redefine methods on Object and have it apply to every object.
  - riffraff 12y ago
    my understanding is that the method call is statically dispatched, and the dispatch is tweaked per module. So, if I pass a String to your api and you invoke method X it will invoke the one redefined in your module, while outside it stays the same (more like scala implicits than ruby's open classes). EDIT: to clarify how I understand this: the authors have basically decided that the module is the element of behavior specialization, and method calls are basically static functions with syntax sugar, and a class is only a data container with some default implementations for the functions.

by Tobu 12y ago

klibertp 12y ago

Variance: I suspect it's a subject to similar restrictions as in Haxe: http://haxe.org/manual/type-system-variance.html http://haxe.org/manual/type-system-variance.html > That's spooky action at a distance. It breaks modularity, could cause packaging hell. Swift, Ruby, Nimrod and Smalltalk are a few languages - out of many, many more - which disagree with you here.

Tobu 12y ago
Nope. In is_subtype: > # If `sub` is a formal type, then it is accepted if its bound is accepted https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d0d9ad0d29b51337/src/model/model.nit#L695 https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d... Ruby is dynamic and the interpreter is feature-rich. People are just exercising self-discipline. Nit intends to be “a robust statically typed programming language” which is very different. Also, could you point me to the Nim feature? All I see is overloading.
- klibertp 12y ago
  > Nope. In is_subtype [...] Oh, ok. So it does look a bit broken then :) > Also, could you point me to the Nim feature? That follows from the fact that `something.method()` is just a syntactic sugar for `method(something)` and that you can write methods for any type anywhere. The example I specifically had in mind was strutils module, which extends a string type with many useful methods. Now that I think about it I'm not sure how Nim would handle two methods of the same name for the same type defined in different places. I think it would refuse to compile such code? But that's a guess only, I'd need to check. EDIT: oh, and I see you complained about redefinition specifically, not about the ability to extend classes in general. Sorry, I somehow missed it.

riffraff 12y ago

IIUC refinements are module-local so they are modular and don't break anything.

Tobu 12y ago
module-local as in, creating a new type that can't be exchanged with the outside? Or converting the value's type on the fly when it gets passed somewhere else? I doubt either would be very usable. Edit: the page refers to open classes, and I think the idea is that you can redefine methods on Object and have it apply to every object.
- riffraff 12y ago
  my understanding is that the method call is statically dispatched, and the dispatch is tweaked per module. So, if I pass a String to your api and you invoke method X it will invoke the one redefined in your module, while outside it stays the same (more like scala implicits than ruby's open classes). EDIT: to clarify how I understand this: the authors have basically decided that the module is the element of behavior specialization, and method calls are basically static functions with syntax sugar, and a class is only a data container with some default implementations for the functions.