Re: Never, ever use the name of a built-in property as a custom property
On Mon, Jan 28, 2019 at 11:49 AM Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > Yet even there you did a great job of rethinking the thing that handles > the data, leaving the data free to be as free as data often is. > Thanks! It was a pain to format, but my recent-acquired awareness of the merge command helped keep it from being a complete disaster. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
Geoff Canyon wrote: > Sure, I'm not arguing for custom property sets -- just saying that if > you *are* going to use them, don't bork the naming convention. Names of prop sets, or the names of keys within a set? On the latter I have mixed feelings. As you know, I have rather a fetish about naming conventions - for handlers, objects, and other things devs deal with. But data is often user-facing, sometimes quite literally so, appearing in fields and other UI elements. Properties are arrays, and arrays are collections of name-value pairs. And with name-value pairs, either the name or the value may be user-facing. So as much as I find good naming conventions useful for both avoidance of technical errors and for readability, anything user-facing cannot be expected to have the same limitations. If a problem arises from a key that conforms to the engine's slim requirements (AFAIK there's only one anymore, that the key length not exceed 255 chars), that would seem an opportunity to rethink the thing that handles the data, rather than the data itself. The DataGrid is a special case, since its name-value pairs are used by developers, yet strives for easy-to-remember names for common things like "style". Yet even there you did a great job of rethinking the thing that handles the data, leaving the data free to be as free as data often is. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
I mean to say the first (and only I am sorry to say) Revolution conference I attended. That sounded like I put on a conference myself. :-) Bob S > On Jan 28, 2019, at 08:02 , Bob Sneidar via use-livecode > wrote: > > This was addressed in my first Revolution conference. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
This was addressed in my first Revolution conference. One of the classes was about naming conventions. Not only do you have to be careful about your names clashing with built-in names, but also reserved words, and the names used by OTHER developers (think plugins). Other languages partially address this by using variable scoping, but you still cannot use reserved words, like names of built in functions. Neither the SE or C/Java compiler would allow it, but properties are not variables per-se. The upshot of the class was that if you are producing something with public distribution in mind, preface ALL your variables and named objects in a way unique to you, so there can be no conflict. Bob S > On Jan 27, 2019, at 15:10 , David Bovill via use-livecode > wrote: > > Yes. I'm scared as well about naming things :) I'm not sure what is safe. > Thee is a tension between making your code readable, and worrying that your > use of a natural language term will clash with some evolution of the > language that may later get added as a native feature. Is nothing safe? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
Yes. I'm scared as well about naming things :) I'm not sure what is safe. Thee is a tension between making your code readable, and worrying that your use of a natural language term will clash with some evolution of the language that may later get added as a native feature. Is nothing safe? On Sun, 27 Jan 2019 at 17:01, Geoff Canyon via use-livecode < use-livecode@lists.runrev.com> wrote: > Sure, I'm not arguing for custom property sets -- just saying that if you > *are* going to use them, don't bork the naming convention. > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
Sure, I'm not arguing for custom property sets -- just saying that if you *are* going to use them, don't bork the naming convention. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Never, ever use the name of a built-in property as a custom property
Hi Geoff, for me the solution is to have a naming convention for all of a
developers / projects work - so everything is prefixed by 4 letters, and
then in the case of custom properties / custom property sets - to migrate
off them and just stick to arrays. The custom property / set syntax was
always confusing, and since we've had arrays there is as far as I can tell
no advantage in using them over simply storing the data you want as an
array in a custom property.
I guess you could combine the two approaches and use a top-level set? But
for me the simplicity of cutting down on that level of architecture and
just using well named custom properties with arrays stored in them has the
advantage that you can refer to them directly in script without any library
to make the job easier?
On Sat, 26 Jan 2019 at 21:34, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:
> https://github.com/gcanyon/navigator/issues/27
>
> I just found that Navigator breaks when editing the custom properties of
> datagrids, because of the custom property dgProps["style"]. When I
> originally added custom properties to the property editor in Navigator it
> was simple: I pretty much had to add one line here and there, and I was
> done. Namely:
>
> if the cCustomProperties of me is true
> then set the customPropertySet of tID to (the cCustomPropertySet of
> me)
>
> And then set the properties as usual. So easy. But setting the property
> breaks if the custom property is "style", with the error that the object
> doesn't have that property.
>
> So now I'm spending time going through Navigator and replacing the above
> with code like this:
>
> put value(merge("the [[pCustomPropertySet]][
> [[quote]][[P]][[quote]]] of [[pID]]")) into pIDP
>
> (if anyone has a cleaner solution, I'd love to hear it)
>
> So: use unique names for your custom properties. Prefix them all with a "u"
> as some people do, for example.
>
> Or don't. Navigator's next update will accommodate you anyway.
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Never, ever use the name of a built-in property as a custom property
https://github.com/gcanyon/navigator/issues/27
I just found that Navigator breaks when editing the custom properties of
datagrids, because of the custom property dgProps["style"]. When I
originally added custom properties to the property editor in Navigator it
was simple: I pretty much had to add one line here and there, and I was
done. Namely:
if the cCustomProperties of me is true
then set the customPropertySet of tID to (the cCustomPropertySet of
me)
And then set the properties as usual. So easy. But setting the property
breaks if the custom property is "style", with the error that the object
doesn't have that property.
So now I'm spending time going through Navigator and replacing the above
with code like this:
put value(merge("the [[pCustomPropertySet]][
[[quote]][[P]][[quote]]] of [[pID]]")) into pIDP
(if anyone has a cleaner solution, I'd love to hear it)
So: use unique names for your custom properties. Prefix them all with a "u"
as some people do, for example.
Or don't. Navigator's next update will accommodate you anyway.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
