YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

Inline annotations (base for type hinting?)
Zylann
#1 Posted : Tuesday, April 28, 2015 7:21:41 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2014(UTC)
Posts: 61
Location: France

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
This is a wider proposal than type hinting, so I created this topic.

I recently discovered TypedLua, an extension of Lua that allows you to optionally write something after values like this:

Code:
local a:int
function foo(v:Vector3, tbl:{}):boolean
--...
end



Alternatively, I saw that Python 3.0 introduced a similar syntax to "annotate" elements inline like this.
You would append ':' to a variable, and put any Python value after, the most common use being optional type hinting.
Annotations with @ existed before, but this alternative syntax was added to unify and simplify the "hinting" process.


I think this would be a useful feature in Squirrel.
The point of this is only to be accessible, not to add extra overhead to the language's performance.

This is not really optional typing (thought it would be a base for users to implement it), and if overused I agree it can become quite ugly.
However, most of the time, it's much more compact, and would simplify editors assistance as well as adding self-documentation to the code.

There is already annotations with </ />, but I find them too heavy:

Code:
// With current annottations
class Platform
{
    </ Type=Vector3 />
    position = null

    </ Type=real />
    speed = 42

    </ Type=SoundList />
    sounds = null

    </ Type=string, Serialized=true />
    _someState = "default value"

}

// With hints
class Platform
{
    position: Vector3
    speed: real = 42
    sounds: [Sound]
    _someState: serialized string = "default value"
}


If specified, these hints could be accessible at the same place as where annotations go, or in a metatable. But unlike annotations, I'm not sure they would they would be tables.

fagiano
#2 Posted : Thursday, April 30, 2015 2:44:24 PM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 1,059

Thanks: 0 times
Was thanked: 79 time(s) in 61 post(s)
Hi,
The type annotation for functions is an interesting addition to consider. however, for classes(based on my usage of class attributes) just having an simple symbol per member would not cut it. While I agree the syntax is more pleasant, functionality wise is a crippled attribute. I personally use class attributes extensively to interface with tools and in our scenario we end up having 4/5 fields per member and not just strings.
something like this:
Code:

class SequenceActor extends Actor
</ clientonly = true />
{
   </ type = "editable", 
        publicname = "Model"
        valtype = "file",
        extension = "mdl",
        defaultdir = "data/models",
        changebehaviour = "refresh",
        description = @"This is the model of the actor."
        />
    _model = "data/models/characters/alphaknight/knight_alpha.mdl";
...
...
...
}


So for classes this kind of annotations feel a bit as a duplication/syntactic sugar. For functions could be interesting, I was thinking of adding attributes to "global" functions but it would clash a bit with the current attributes that are per "member". Mmhh

ciao
Alberto
Follow me on Twitter @squirrellang
Zylann
#3 Posted : Friday, May 1, 2015 3:47:52 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 6/25/2014(UTC)
Posts: 61
Location: France

Thanks: 1 times
Was thanked: 2 time(s) in 2 post(s)
I agree that at some point, inline attributes get ugly when we want to put a lot of data in them.

I didn't mentioned Godot, which has an alternate system for class attributes: for instance, to specify a member which is saved, you would put "export" before it. If you want this member to be edited and declaration is not enough for the editor to guess, you put the type into export(...), and so on for additional hints (https://github.com/okamstudio/godot/wiki/gdscript).

The use of inline annotations on class members is based on my own use of attributes too, which is more tag-based (array) than key/value (tables), so it's a bit subjective. I would find it an interesting alternative, if used the right way.

Types of members could be hinted by simply initializing them. However this leads to a second problem I have with Squirrel: when the type is an object, it will be the same for all instances. I don't like this very much, but that's another topic^^

Anyway, if at least it could be implemented on functions, that would be cool already :)

Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.349 seconds.