In the IDE, if I type Parse, I will get the choice between ParseDate, ParseJSON, etc.
On the other hand (literally), if JSON was used as Prefix, I would get a far better list of choice.
You want to make things simple for the Newbies ?
This way can be better, maybe.
PS: that is the way I name objects in my interface (Date_Start and Date_End are two example I use often). And after checking, it seems that is the way it is done before 2019r2.
BTW: is this is the way API 2 works ? And so what A simple Property set at project creation time and Xojo assume code is API 1 or API 2
Scrap a good idea because another was implemented strangely ?
[quote=472748:@Markus Rauch]agree the naming is not nice (and annoying in auto complete) as example in listbox
AddRow
RemoveRowAt
RemoveAllRows
RowTagAt
Rows
Sort
should be
.Rows.Add
.Rows.Find
.Rows(0).Tag =
.Rows.Remove
.Rows.RemoveAll
.Rows.Sort
and because the name listbox and not rowbox
.List.Sort
.List.Clear[/quote]
Something like that. There seems to be also the issue of having different types of exceptions:
Some return RuntimeException ? That should never be the case.
Some return like JSONITem; invaldArgumentException and InvalidJsonException why not just JSONException? Not sure why it has to be such a spagetti.
its bad at coding because the methods are in the wrong hierarchy and result in long names.
the auto complete is always out of context and show everything.
When designing a language, functions and methods names are grouped in opposite ways to make it easier to find the desired options in autocomplete. Functions usually are better described as NounVerb, and methods VerbNoun (a noun in a method is optional, but some designers prefer this tautological way to make it clearer when reading the final result under certain contexts as x.Clear() vs x.ClearString() <>). So we have things like: StringExplode(“abc”), and String.Explode(“abc”), or s.ExplodeString(“abc”) << function: StringExplode(); methods: Explode() or ExplodeString() >> all well designed. But function ExplodeString(), and method String.StringExplode() are not.
