Issues and problems
Community Forums/Monkey2 Talk/Issues and problems
| ||
| ***** Modules/namespaces etc ***** TODO! ***** Properties ***** A more succinct syntax for specifying properties would be nice. ***** Virtual/Overrides modifier? ***** Should methods have a 'Virtual' modifier indicating they are virtual? Should methods have an 'Override' modifier to prevent user accidentally overriding a super class method? ***** Should strings/arrays be objects? ***** This is kind of elegant, but my biggest issue with it is that string/array values can then potentially be null, and you start getting a lot of code that looks like... if blah and blah.Length ...to avoid 'null object' exceptions. Currently, strings/arrays are effectively values, and values can never be null. I guess they could be 'objects that are never null', but that seems even clunkier to me. |
| ||
' creates a field by converting first character to lowercase, one or both of Set/Get can exist Property Foo:String() Get Set Field foo:String Property Foo:String() Get Return foo End Property Foo:Void(value:String) Set foo = value End |
| ||
| Quite like the general approach - does the first line 'produce' the rest of the code? Can you show a hypothetically runnable example? In general, it's very useful for me if you can do this with any example ideas, as I'm not always sure what you're getting at! |
| ||
Property Foo:String() Get Set Generates Monkey: Field foo:String Method Foo:String() Property Return foo End Method Foo:Void(value:String) Property foo = value End Also: Property Foo:String() = "hello" Get Generates read only: Field hello:String Method Foo:String() Property Return hello End |
| ||
| How would the compiler know if... Property Foo:String() Get ...was declaring a 'default' getter (ie: compiler generates get code), or a getter implementation (ie: coder generates get code). Perhaps something like: Property Foo:String() Get Default 'compiler generates code Property Foo:Void( value:String ) Set 'actual code... End |
| ||
How about...
class C
'direct read/write property - syntactically the same as a field.
property Foo:int
method update:void()
Print Foo 'use property via getter
Print Foo.value 'access property value directly. always private to C.
end
end
class D
'read/write property - a default getter will be created since none is declared.
property Foo:void( foo:int )
value=foo
end
end
class E
'read/write property - a default setter will be created since none is declared.
property Foo:int()
return value
end
end
class F
'read/write property - no default methods created since both getter and setter are declared.
property Foo:void( foo:int )
value=foo
end
property Foo:int()
return value
end
end
class G
'write only property due to nodefault qualifier
property Foo:void( foo:int ) nodefault
value=foo
end
end
class H
'read only property due to nodefault qualifier
property Foo:int() nodefault
return value
end
end
This makes it easy to write the common cases, where you wont both read and write access. For read only/write only access, you just add a 'nodefault' qualifier. This could probably be renamed to 'readonly' and 'writeonly', and an optional readwrite added . The redundant case works just like a field decl, and the compiler can just rewrite it as such. |
| ||
| How would the compiler know if... Because the compiler would know whether the user had implemented their own. It's no different to @synthesize in Objective-C. Print Foo.value But this makes it look like an object, which it's not. Also I don't think you should be able to get to the "raw" value unless the property is explicitly returning a private field, in which case there's no need. I think your first suggestion (post #5) is the cleanest. Not so sure about the "Default" thing though, I don't really like reusing keywords. It'd be nice if the compiler was smart enough to detect that the next line contained no "method-ish" code. Or, *cough* mandatory semicolons... |
| ||
| marksibly wrote: ***** Virtual/Overrides modifier? ***** Should methods have a 'Virtual' modifier indicating they are virtual? Yes. [Public] [Virtual] Method Name:ReturnType(Arguments)
[Method-Body]
End
'
' One-Liner (no body):
'
[Public] [Virtual] Method Name:ReturnType(Arguments) = 0 marksibly wrote: Should methods have an 'Override' modifier to prevent user accidentally overriding a super class method? Yes. It prevents errors/mistakes and is a clear/clean syntax. [Public/Private/Protected] [Override] Method Name:ReturnType(Arguments)
[Method-Body]
End
[Override] [Public/Private/Protected] Method Name:ReturnType(Arguments)
[Method-Body]
End
[Override] Method Name:ReturnType(Arguments) ' [Public/Private/Protected] already known, so it's optional
[Method-Body]
EndMissing 'Override' for an existing method in the parent class should give a error to prevent overriding by accident. |
| ||
| > But this makes it look like an object, which it's not. No, it's just a namespace, like List<T> or mojo.graphics etc. I don't see any problem with this. It means we don't 'pollute' the class namespace with a dummy field. > Also I don't think you should be able to get to the "raw" value Only private members of the same class can access Foo.value. |
| ||
| Please, make all visibility modifiers (private, public, etc) affect the immediate definition instead of all subsequent definitions. Otherwise the modifier can be lots lines of code up in code, making code less easy to follow. |
| ||
| @ziggy: Please, make all visibility modifiers (private, public, etc) affect the immediate definition instead of all subsequent definitions. Otherwise the modifier can be lots lines of code up in code, making code less easy to follow. This. I don't like the idea of having to scroll up the code to find out the visibility of a method/function/field. @marksibly: Should methods have a 'Virtual' modifier indicating they are virtual? ... Should methods have an 'Override' modifier to prevent user accidentally overriding a super class method? Yes to both these. I never really liked the "virtual by default" functionality in Java and Monkey. As a framework author, I'd like to define what developers can safely override rather than second guess which methods should be final. @Danilo: Missing 'Override' for an existing method in the parent class should give a error to prevent overriding by accident. Agreed. It also helps in the case that an overridden method is removed from the base class. On the subject of visibility modifiers, I think Private should apply to the class, and not the entire module. This is where the Internal keyword could make a reappearance... |
| ||
| I was torn on scope directives being used the way they are in Monkey, but I grew to like them quite a bit. They force people to organize their code or else make a huge mess of extra lines, and languages that use this syntax tend to also enforce this organization. Requiring a bunch of access modifiers on every definition line would definitely make coding more tedious, and I'm not sure I want to go back to that way of doing things! Proper Monkey looks more tidy, even if that makes it difficult on people whose coding style likes to lump members together by related functionality regardless of access level. I'll also throw my hat in there that I like the overridable-by-default nature of Monkey; you can tell who is most comfortable in certain languages in here based on the fact they're being referred to as virtual methods, as if the natural state of things in 2015 is that methods should be explicitly marked overridable. I imagine that these sorts of safety-features only existed mainly to avoid hazards from language features like multiple inheritance that almost everyone agrees now isn't a very good idea. I believe this fundamental change to the default access level for every method out there is neither necessary nor warranted. As for properties! I started writing a post about them in the language features thread before I stumbled across here, and I'm happy to see that we may be seeing a more advanced property syntax in Monkey2. (One can only hope!) Mark, if you would please have a gander at this post, you can see a couple more syntax suggestions. One uses a similar Get/Set syntax as Samah's suggestion, based on how VB.NET does it; the other uses a more Python-style / Monkey scope directive-style way of defining getter/setter blocks and is nice and tidy. |
| ||
| I don't really have the time to state my opinions on all of Monkey 2's intended feature set, but I don't think some of you guys get the point of Monkey's method system. It's not "virtual by default", it's "mutable by default". I honestly don't see the point of a "Virtual" or "Override" keyword, as it's counter intuitive to Monkey's current method system. The biggest downside to the way Monkey does it right now is the fact that you have to assume (At worst possible conditions) that a virtual call is taking place, if you don't explicitly declare a method as 'Final'. With Monkey's current source generation system, optimization through encapsulation goes straight out the window. Basically, the only classes that don't have implied virtual calls are the classes at the end of the inheritance tree. These days, compilers like g++, MSVC, and Clang have steps to reduce virtual calls, but most of those optimizations are completely useless to Monkey. There's really just no way to know the context an object is being used in, unless the compiler understands that it's an encapsulated situation beforehand. Basically, in Monkey, methods are a mutable construct, but out of Monkey, the mindset's different. I guess it really depends on how far down the compatibility rabbit hole Mark wants to go. Personally, I think source-to-source from the current version of Monkey to Monkey2 is the best idea for compatibility. My personal take on the explicit "Virtual" keyword is the opposite. Make methods the same kind of dynamic construct they are now, but make 'Final' (Or a different keyword) denote that the method will not be used virtually from that stage in the inheritance tree. Oh, and just to make this clear, having 'Public', 'Private', 'Protected', etc, on the same line is not only ugly to me, but it makes everything a mess. That especially applies to consistency in your own code. There's a reason C++ doesn't force you to write 'public' everywhere in a class, it just adds clutter. I think people's problems with 'Public' and 'Private' are more of an organization thing. You should dedicate areas to be public and private, not using them all over the place. Having "in-line" scope specifiers would be a nice option, though. Personally, I don't think we need them, but some may disagree. And honestly, readability shouldn't matter over write-ability. I don't think "Public Virtual Method Name:Type() Override" looks good at all, and when you add C++'s not so amazing "= 0" syntax, you're asking for trouble. Not just from a readability standpoint, but also writing that tons of times. Keep the 'Abstract' keyword, please. And I'd like to not have to write a ton of characters to do the same thing. You could have similar control treating methods the other way; explicitly stating if they're final / at the end of the "virtual scope". Also, @Nobuyuki: Multiple inheritance is great when used correctly, but I agree that Monkey doesn't need it. Well, other than interfaces, but they can be over used at times. Mark said he wanted to add delegates of some sort, so that would probably fix my problems with interfaces. I'll just stick to my generic "node-based" class structure (Which I hope will work with Monkey2). Changing how properties work is probably for the best, though. Alright, there's too much to cover, so I'll leave it at that. Good to hear about the new project, Mark. |
| ||
| Make it possible to use 'old' monkey code in the new monkey2 My target is ios/desktop/[android] and i'm not using fancy things/modules right now. If I want to buy the new monkey2, I don't want to fully rewrite all my code. So it would be nice as you can import old monkey code, and convert it once to monkey2 code. And make this possible (if its not already possible) ' i = 10 i++ ' i = 11 |
| ||
| @GC-Martijn: If I want to buy the new monkey2, I don't want to fully rewrite all my code. If you don't want to use the new features of Monkey 2, why can't you just compile your code with Monkey 1, then? |
| ||
| @Samah I want to use and buy Monkey2, but I don't want to rewrite/check all the monkey1 10000 lines by hand. Its like microsoft does with all the visual studios, with every new visual studio its possible to import the old code once. When there are problems, then you see exactly where. Why would it not be possible to convert monkey1 code to monkey2 code ? (maybe not for 100%, but for 90% its oke to check the other 10% by hand) |
| ||
| Please, make all visibility modifiers (private, public, etc) affect the immediate definition instead of all subsequent definitions. Otherwise the modifier can be lots lines of code up in code, making code less easy to follow. Massive YES to this too. The current monkey approach seems lazy to code in an otherwise fairly strict language. Also massive yes to auto/inline getter setters. I hate having to name fields with a _. |
| ||
| I will be honest - I don't really see the need for any of these. I dislike properties and never use them - if I want a variable I use a variable and if I want a method I use a method - so I guess making them better for people who do may well be a good idea. Agree with those who are opposed to clutter. I can see merits in a line of modifiers in front of every method, but I am also cognizant of the merits of NOT needing that, which is the Monkey way so far. Remember, Monkey is supposed to be for inexperienced as well as experienced coders. What I do is separate the public and private methods by making a dummy function like this: Private Function ___________Private__________:Void() End Everything below this is private, so I always know where I am just by looking in the code window. Personally I'd like to see inlining (for intense graphics processing, optimising the use of fake multi-dimensional arrays, etc.) |
| ||
| Heh, slighty tongue in cheek idea: A new Modify keyword that allows you to insert modifiers before a method that will apply only to it: Modify Private Virtual MyMethod:Void() Those who like typing lots of keywords will have a bonus keyword to type, and those who don't can stick to the previous system ;-) |
| ||
| Modify Private Virtual MyMethod:Void() Noooooo! This would be better: Do Modify To Private And Virtual MyMethod:ReturnNothing(empty) :-))) |
| ||
| Agree with those who are opposed to clutter. I can see merits in a line of modifiers in front of every method, but I am also cognizant of the merits of NOT needing that, which is the Monkey way so far. Remember, Monkey is supposed to be for inexperienced as well as experienced coders. Well, IMHO it is much better to be able to group class members from a functionality perspective, instead of being forced to group them by visibility, because the language is defined like this. Having all unrelated attributes together because they're private has no benefits, and does not help following class logic in any way.Also the scroll up & down requirement just to know if you're inside a private or public area of the class, is very inconvenient sometimes. There's a reason why all languages that derived from C++ syntax, AFAIK did change this |
| ||
| The way I look at it, most of them should generally be private, so grouping the public ones together IS quite reasonable. After all, somebody using the class shouldn't be looking at the private members anyway! |
   |