[Bloc] Do we want <return: #Point> or <return: Point>
Locked
12
12
 
|
On Tue, Feb 23, 2016 at 8:17 PM, stepharo <[hidden email]> wrote:
> I do not think that Pharo will become a static language :) > For the moment we can let it as a documentation. > Now I would prefer to have tests because such annotations may be obsolete. Maybe not if those pragmas become *active* when the unit tests are run. Then they might be treated like asserts without application runtime penalty. The benefit over unit tests for package A, would be these asserts would be active when called from the unit tests of package B. (??) cheers -ben |
Re: [Bloc] Do we want <return: #Point> or <return: Point>
|
|
In reply to this post by stepharo
On Tue, Feb 23, 2016 at 12:47 AM, stepharo <[hidden email]> wrote: Hi Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot |
Re: [Bloc] Do we want <return: #Point> or <return: Point>
|
|
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) I had the following pragma: On Tue, Feb 23, 2016 at 12:47 AM, stepharo <[hidden email]> wrote: Hi Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot |
Re: [Bloc] Do we want <return: #Point> or <return: Point>
|
|
In reply to this post by Ben Coman
2016-02-23 12:00 GMT+01:00 Ben Coman <[hidden email]>: On Tue, Feb 23, 2016 at 5:33 PM, Tudor Girba <[hidden email]> wrote: It feels it does not really work well as for example #at: is used in many places, and on Array the return type is Object whereas on ByteArray it is SmallInteger. Other frequent messages have the same problems (#add:, #+ etc) and they are the most used. Usually for partial typing, one types only: - return type of methods/closures - parameters of methods/closures - instance variables Hack (optionally typed PHP by Facebook) is done like that, one can type only these 3 aspects and all the types are fully optional. Reportedly it is very good. You can read about it here: https://docs.hhvm.com/hack/types/annotations. If one follows the microsoft guidelines to develop in C#, one also types these 3 aspects only. Although in the case of C# those 3 aspects have to be typed, they can't remain untyped as in Hack, and even if it's optional, typing is available for the rest of the code. That implies that according to development guidelines, no temporary variables or literal variables are typed in both languages. Typed people are not confused, as the IDE infers for them the type of any variable they mouse over. Untyped people have little constraints compared to typing everything. The Hack direction is probably the direction to go to introduce types in Pharo like the Hack guys did for PHP. Untyped people can keep typing nothing, while typed people still have all the information they need. With a setting to display or not the type annotations in the source code in the core libraries, everyone is happy.
|
Re: [Bloc] Do we want <return: #Point> or <return: Point>
|
|
In reply to this post by Eliot Miranda-2
2016-02-23 18:03 GMT+01:00 Eliot Miranda <[hidden email]>:
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
|
Re: [Bloc] Do we want <return: #Point> or <return: Point>
|
|
2016-02-25 15:25 GMT+01:00 Clément Bera <[hidden email]>:
I am about to change this (with the exception for <primitive:...error:>) 17696 RBParser should not allow variable names for pragma arguments
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |