Nice http://wiki.contextgarden.net/Module_Namespaces Can I register lscarso[a-zA-Z]* ? -- luigi
On 2010-11-18 <10:13:07>, luigi scarso wrote:
Nice http://wiki.contextgarden.net/Module_Namespaces
Can I register lscarso[a-zA-Z]* ? Maybe we should consider an auction; in the future this could get as busy as trading domain names.
Philipp
-- luigi ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Am 18.11.2010 um 10:13 schrieb luigi scarso:
Nice http://wiki.contextgarden.net/Module_Namespaces
Can I register lscarso[a-zA-Z]* ?
Why? The obvious method is to use the same name for the namespace as you use for your module name or the command names, e.g. the fancybreak module has the commands \definefancybreak, \setupfancybreak and the namespace „fancybreak“ and Adityas visualcounter module can use the namespace „visualcounter“ (there is no need to use capitals). Wolfgang
On Thu, Nov 18, 2010 at 7:08 PM, Wolfgang Schuster
Am 18.11.2010 um 10:13 schrieb luigi scarso:
Nice http://wiki.contextgarden.net/Module_Namespaces
Can I register lscarso[a-zA-Z]* ?
Why? The obvious method is to use the same name for the namespace as you use for your module name or the command names, e.g. the fancybreak module has the commands \definefancybreak, \setupfancybreak and the namespace „fancybreak“ and Adityas visualcounter module can use the namespace „visualcounter“ (there is no need to use capitals).
I just want to register my namespace(s) to be sure to avoid conflicts not only for modules but also for lua code Think for example to something like document.lscarso = document.lscarso or {} function document.lscarso.lua_pixGetPixel(pixs,x,y) local scratch = 0 local res = '' scratch = leptonica.uti_getref_l_uint32() if (leptonica.pixGetPixel(pixs,x,y,scratch) == 0) then res = leptonica.uti_valref_l_uint32(scratch) else print("! Error on ",x,y) res = '' end return res end with a registered namespace (or, better, a suffix) I will be sure to avoid conflicts forever -- luigi
Am 18.11.2010 um 19:33 schrieb luigi scarso:
I just want to register my namespace(s) to be sure to avoid conflicts not only for modules but also for lua code
Good idea and it’s not a problem to reserve „lscarso“ for you but i ask myself which of these tables (luat-ini.lua) are available for users: userdata = userdata or { } -- might be used thirddata = thirddata or { } -- might be used moduledata = moduledata or { } -- might be used documentdata = documentdata or { } -- might be used parametersets = parametersets or { } -- experimental document = document or { } Wolfgang
Hi all, On 2010-11-29 <19:17:00>, Wolfgang Schuster wrote:
Am 18.11.2010 um 19:33 schrieb luigi scarso:
I just want to register my namespace(s) to be sure to avoid conflicts not only for modules but also for lua code
Good idea and it’s not a problem to reserve „lscarso“ for you but i ask myself which of these tables (luat-ini.lua) are available for users:
userdata = userdata or { } -- might be used thirddata = thirddata or { } -- might be used moduledata = moduledata or { } -- might be used documentdata = documentdata or { } -- might be used parametersets = parametersets or { } -- experimental
document = document or { }
If I may add to this question: I am using “job.variables” as kind of base for my private use area (not for modules, though) -- bad habit or valid alternative? Thanks, Philipp
Wolfgang
___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On Mon, Nov 29, 2010 at 7:52 PM, Philipp Gesang
If I may add to this question: I am using “job.variables” as kind of base for my private use area (not for modules, though) -- bad habit or valid alternative? Without a valid namespace there is always the risk of conflicts.
-- luigi
On 29-11-2010 7:52, Philipp Gesang wrote:
If I may add to this question: I am using “job.variables” as kind of base for my private use area (not for modules, though) -- bad habit or valid alternative?
bad habit .. use documentdata.pg or so Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Dear Hans, On 2010-12-06 <17:50:15>, Hans Hagen wrote:
On 29-11-2010 7:52, Philipp Gesang wrote:
If I may add to this question: I am using “job.variables” as kind of base for my private use area (not for modules, though) -- bad habit or valid alternative?
bad habit .. use documentdata.pg or so
you once[1] recommended “job.variables.tobesaved” for situations where something has to be stored for successive runs. Is the “more robus user space” for this that you mentioned already implemented? Regards, Philipp [1] http://archive.contextgarden.net/message/20100427.214703.0d3775c4.en.html -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On 29-11-2010 7:17, Wolfgang Schuster wrote:
Am 18.11.2010 um 19:33 schrieb luigi scarso:
I just want to register my namespace(s) to be sure to avoid conflicts not only for modules but also for lua code
Good idea and it’s not a problem to reserve „lscarso“ for you but i ask myself which of these tables (luat-ini.lua) are available for users:
userdata = userdata or { } -- might be used thirddata = thirddata or { } -- might be used moduledata = moduledata or { } -- might be used documentdata = documentdata or { } -- might be used parametersets = parametersets or { } -- experimental
document = document or { }
userdata = userdata or { } -- for users (e.g. functions etc) thirddata = thirddata or { } -- only for third party modules moduledata = moduledata or { } -- only for development team documentdata = documentdata or { } -- for users (e.g. raw data) parametersets = parametersets or { } -- experimental for team document = document or { } -- only for context itself thirddata.lscarso = thirddata.lscarso or { } thirddata.lscarso.whatever = { } function thirddata.lscarso.whatever.glasses() return "still at bachotek" end ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
Am 18.11.2010 um 19:33 schrieb luigi scarso:
I just want to register my namespace(s) to be sure to avoid conflicts not only for modules but also for lua code
Good idea and it’s not a problem to reserve „lscarso“ for you but i ask myself which of these tables are available for users: userdata = userdata or { } -- might be used thirddata = thirddata or { } -- might be used moduledata = moduledata or { } -- might be used documentdata = documentdata or { } -- might be used parametersets = parametersets or { } -- experimental document = document or { } Wolfgang
On 18-11-2010 10:19, luigi scarso wrote:
On Thu, Nov 18, 2010 at 10:03 PM, Aditya Mahajan
wrote: On Thu, 18 Nov 2010, Wolfgang Schuster wrote:
(there is no need to use capitals).
Thanks. Old habits die hard. Camel case is not bad at all --- it's a matter of points of view
best use lowercase systematically then users can use uppercase or a mix and not clash with built in names Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, 18 Nov 2010, Hans Hagen wrote:
On 18-11-2010 10:19, luigi scarso wrote:
On Thu, Nov 18, 2010 at 10:03 PM, Aditya Mahajan
wrote: On Thu, 18 Nov 2010, Wolfgang Schuster wrote:
(there is no need to use capitals).
Thanks. Old habits die hard. Camel case is not bad at all --- it's a matter of points of view
best use lowercase systematically
then users can use uppercase or a mix and not clash with built in names
As a module writer, it is not always clear whether you should follow the conventions for a user (use upper or mixed case to avoid clash) or a developer (use lowercase systematically). Aditya
On 18-11-2010 10:48, Aditya Mahajan wrote:
On Thu, 18 Nov 2010, Hans Hagen wrote:
On 18-11-2010 10:19, luigi scarso wrote:
On Thu, Nov 18, 2010 at 10:03 PM, Aditya Mahajan
wrote: On Thu, 18 Nov 2010, Wolfgang Schuster wrote:
(there is no need to use capitals).
Thanks. Old habits die hard. Camel case is not bad at all --- it's a matter of points of view
best use lowercase systematically
then users can use uppercase or a mix and not clash with built in names
As a module writer, it is not always clear whether you should follow the conventions for a user (use upper or mixed case to avoid clash) or a developer (use lowercase systematically).
sure, but then you can use prefixes: \@@fancybreakhelper and so (there was a time that one would save on characters in order not to overflow string space but nowadays it's no problem) ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, Nov 18, 2010 at 10:48 PM, Aditya Mahajan
On Thu, 18 Nov 2010, Hans Hagen wrote:
On 18-11-2010 10:19, luigi scarso wrote:
On Thu, Nov 18, 2010 at 10:03 PM, Aditya Mahajan
wrote: On Thu, 18 Nov 2010, Wolfgang Schuster wrote:
(there is no need to use capitals).
Thanks. Old habits die hard.
Camel case is not bad at all --- it's a matter of points of view
best use lowercase systematically
then users can use uppercase or a mix and not clash with built in names
As a module writer, it is not always clear whether you should follow the conventions for a user (use upper or mixed case to avoid clash) or a developer (use lowercase systematically). Because really there is no difference between "user" and "developer" That what I think: lower case name are for files in base All others should use a distinct "namespace" (ie lscarso , amahajan etc or Filters )
-- luigi
participants (5)
-
Aditya Mahajan
-
Hans Hagen
-
luigi scarso
-
Philipp Gesang
-
Wolfgang Schuster