[Bloc] Do we want <return: #Point> or <return: Point>
Hi I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code. Stef
2016-02-23 9:47 GMT+01:00 stepharo <stepharo@free.fr>:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
I would like to know for what this is used. I don't like it.
Stef
I donât like it too. Alain
Le 23 févr. 2016 à 09:50, Nicolai Hess <nicolaihess@gmail.com> a écrit :
2016-02-23 9:47 GMT+01:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
I would like to know for what this is used. I don't like it.
Stef
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used? Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Because we may have code not present and still want to load the code.
I think it's just visual, because it's still referenced as string in the pragma itself. For example Person>>contact <DCType: Contact multiplicity: #(1 '*')> ^ contact ifNil: [ contact := OrderedCollection new ] But, (Person>>#contact) pragmas first arguments first class == ByteSymbol Does it fail to load otherwise? Peter On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Old compiler does not allowed <return: Point> only <return: #Point> And I think opal should behave the same (not fixed yet) 2016-02-23 11:01 GMT+01:00 Peter Uhnák <i.uhnak@gmail.com>:
Because we may have code not present and still want to load the code.
I think it's just visual, because it's still referenced as string in the pragma itself. For example
Person>>contact <DCType: Contact multiplicity: #(1 '*')> ^ contact ifNil: [ contact := OrderedCollection new ]
But, (Person>>#contact) pragmas first arguments first class == ByteSymbol
Does it fail to load otherwise?
Peter
On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ok so I will use # Stef Le 23/2/16 11:09, Nicolai Hess a écrit :
Old compiler does not allowed <return: Point> only <return: #Point>
And I think opal should behave the same (not fixed yet)
2016-02-23 11:01 GMT+01:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
>Because we may have code not present and still want to load the code.
I think it's just visual, because it's still referenced as string in the pragma itself. For example
Person>>contact <DCType: Contact multiplicity: #(1 '*')> ^ contact ifNil: [ contact := OrderedCollection new ]
But, (Person>>#contact) pragmas first arguments first class == ByteSymbol
Does it fail to load otherwise?
Peter
On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote:
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Alexandre
> On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: > > Hi > > I saw that something <return: #Point> or <return: Point> > I do not know why but I have the impression that <return: #Point> is better. > Because we may have code not present and still want to load the code. > > Stef >
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Sounds like a recipe for creating documentation that gets out of sync quickly/has bugs of its own, if you ask me... For instance, in the example, it seems weird multiplicity: (1 '*') when the method returns an empty collection if contact is nil (multiplicity 0) Cheers, Henry
On 23 Feb 2016, at 11:01 , Peter Uhnák <i.uhnak@gmail.com> wrote:
Because we may have code not present and still want to load the code.
I think it's just visual, because it's still referenced as string in the pragma itself. For example
Person>>contact <DCType: Contact multiplicity: #(1 '*')> ^ contact ifNil: [ contact := OrderedCollection new ]
But, (Person>>#contact) pragmas first arguments first class == ByteSymbol
Does it fail to load otherwise?
Peter
On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote: Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Feb 23, 2016 at 11:21 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
Sounds like a recipe for creating documentation that gets out of sync quickly/has bugs of its own, if you ask me... For instance, in the example, it seems weird multiplicity: (1 '*') when the method returns an empty collection if contact is nil (multiplicity 0)
The multiplicity is unrelated to the question (it's from my project), I was merely demonstrating the ByteSymbol storage. But thanks for the bug report, I'll have to fix that. :) Peter
On 23 Feb 2016, at 10:43, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Apparently just for documentation Still this is a dangerous 'precedent' as it might give the wrong impression
Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Pablo Tesone Phd was on type inferencing but he accepted another PhD topics with Noury and us. Le 23/2/16 10:43, Alexandre Bergel a écrit :
Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used?
Alexandre
On Feb 23, 2016, at 5:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Stef
On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot
There is also <return: BlElement or: nil> to indicate explicitly that user must check for nil. There are only a few methods in element (#owner and some collection related methods like "find element such that") that may return nil. Ideally syntax checker should take into account that method can return nil and indicate it somehow to user. Annotating return values is very common nowadays in popular dynamically typed languages to help static analysis of IDE. Annotating return values allows to instantly browse its class. Small script can remove those annotations and asserts from code during build for production on CI server. I don't understand why only symbols are allowed. In any console string parameter without spaces can be used directly without quotes. So for pragmas should work (and it works in latest pharo) <return: Point> <return: nil> <return: #Point> <return: 'Point'> <return: #'Point of view'> <return: 'Point of view'> I had the following pragma: <return: MyMagicClass> After renaming of MyMagicClass in nautilus it was also renamed in pragma. On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot
2016-02-23 18:03 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Given the current semantics of pragmas only <return: #Point> is valid.
Well, yes... In fact, Opal compiles <return: Point> as <return: #Point>. It does not change the semantics. I think the real question is: "Do we allow, in the specific case of pragma, symbols to by written without the # ?" We already allow "[ nil ]" to be written as "[ ]", and the "^self" at the end of each method to be omitted. We could have more specific cases so it won't be too trivial for unaware people to understand the semantics. We can already see that the syntax colorer is not aware of this specific case, so it colors Point in <return: Point> as a Literal Variable instead of a symbol, which leaded many people here to confusion. *About renaming...* When renaming a class, it checks all the symbol references too, so, assuming you have a class Banana and the following code: Coconut >> getSomething <return: Banana> <return: #Banana> Banana new. ^ #Banana When we rename the class Banana to Cauliflower, the method is automatically changed to: Coconut >> getSomething <return: #Cauliflower> <return: #Cauliflower> Cauliflower new. ^ #Cauliflower Again, in this case, as for syntax coloring, the system is not aware that it should rename <return: Banana> to <return: Cauliflower> and not <return: #Cauliflower>, so as it uses standard symbol terminology
_,,,^..^,,,_ best, Eliot
2016-02-25 15:25 GMT+01:00 Clément Bera <bera.clement@gmail.com>:
2016-02-23 18:03 GMT+01:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo@free.fr> wrote:
Hi
I saw that something <return: #Point> or <return: Point> I do not know why but I have the impression that <return: #Point> is better. Because we may have code not present and still want to load the code.
Given the current semantics of pragmas only <return: #Point> is valid.
Well, yes...
In fact, Opal compiles <return: Point> as <return: #Point>. It does not change the semantics.
I think the real question is: "Do we allow, in the specific case of pragma, symbols to by written without the # ?"
I am about to change this (with the exception for <primitive:...error:>) 17696 <https://pharo.fogbugz.com/f/cases/17696/RBParser-should-not-allow-variable-n...> RBParser should not allow variable names for pragma arguments
We already allow "[ nil ]" to be written as "[ ]", and the "^self" at the end of each method to be omitted. We could have more specific cases so it won't be too trivial for unaware people to understand the semantics.
We can already see that the syntax colorer is not aware of this specific case, so it colors Point in <return: Point> as a Literal Variable instead of a symbol, which leaded many people here to confusion.
*About renaming...*
When renaming a class, it checks all the symbol references too, so, assuming you have a class Banana and the following code:
Coconut >> getSomething <return: Banana> <return: #Banana> Banana new. ^ #Banana
When we rename the class Banana to Cauliflower, the method is automatically changed to:
Coconut >> getSomething <return: #Cauliflower> <return: #Cauliflower> Cauliflower new. ^ #Cauliflower
Again, in this case, as for syntax coloring, the system is not aware that it should rename <return: Banana> to <return: Cauliflower> and not <return: #Cauliflower>, so as it uses standard symbol terminology
_,,,^..^,,,_ best, Eliot
participants (10)
-
Alain Plantec -
Alexandre Bergel -
Aliaksei Syrel -
Clément Bera -
Eliot Miranda -
Henrik Johansen -
Nicolai Hess -
Peter Uhnák -
stepharo -
Sven Van Caekenberghe