First things first...

[Rai López]

Hi, again. I've been meaning to ask for a while a couple of apparently basic stuff about Moho's tool scripts that always called my attention and I didn't know exactly how to do it (or maybe I didn't dare ), but finally here I go:

• If first things first, the very first thing you find when you open a tool/menu script is this:

  Code: Select all

  -- **************************************************
  -- Provide Moho with the name of this script object
  -- **************************************************
  
  ScriptName = "LM_AddBone"
  
  

  Ok, and what I see is this is a global variable named "ScriptName" and it is used for EVERY Moho tool, so I understand it gets the value, in this case: "LM_AddBone", at the time the script is read/loaded by Moho and then its value gets overwritten as soon as the next tool (lm_bind_layer.lua, I guess) start to be read/loaded. So... what it's really used for? I think I can glimpse it has to do with OOP, and it is what Moho uses to internally define/create the object the tool itself is going to be after all, but I always thought the next line: "LM_AddBone = {}" was indeed all what Moho really needed to create such OOP based object, and hence my doubt. So what do you think it exactly does? My bet is ScriptName = "LM_AddBone" tells Moho to internally create an object called LM_AddBone with which a line afterwards can bound the homonym table (LM_AddBone = {}), or something so... But I'm far to be sure and I wanted to try to get some OOP concepts and understand a little better how things work under the hood regarding tools, if possible.

• And, since we are at it, one of the next things you also can find is:

  Code: Select all

  function LM_AddBone:Name()
  	return "Add Bone"
  end
  
  [...]
   
  function LM_AddBone:UILabel()
  	return(MOHO.Localize("/Scripts/Tool/AddBone/AddBone=Add Bone"))
  end
  

  And for simple curiosity... why a function? I mean, why declare a bunch of functions for only returning some strings and not a simple table entry instead like for example: LM_AddBone.Name = "Add Bone", LM_AddBone.Version = "6.0", etc. which would be simpler and equally accesible after all? Could it be for a reason/advantage, or just because it's preferred when working under the OOP paradigm for being on the safe side in case you need more functionality than what a simple variable can offer in the future or whatever? Or maybe because that way is unchangeable? Of course, I'm only talking here about these first super-simple "General information" functions and not about the other ones along the scripts.

Well, that's all... sorry if I went too basic with this, but I think I couldn't hold it inside anymore

[SimplSam]

1. ScriptName

I would image this is just used during initialisation by the Scripts Loader when adding each script to the script repository, and then disregarded -or- reused.

the "LM_AddBone = {}" etc. is just a table assignment, which becomes significant when associated with the relevant script object in the repository. Without ScriptName it would be difficult to determine that this table was the actual script name - especially when you can name scripts whatever you like. I don't think the declaration position (line #) has any significance other than for the Lua code to actually work.


2. Method() vs .property?

I think it is probably because in Lua a method output is One-way / Read-only. Table variables/Properties tend to be Two-way Read/Write. So function calls offer a level of value protection (even though you can override the functions). I read that there are ways to make variables/tables read-only but involves messing with metaTables and other funky stuff.

[hayasidist]

why a function? interesting question.

I feel it **might** be more to do with the fact that the Moho "core" in written in C, and it's likely easier to call a function than to access a Lua Global.

Why multiple functions when "one" would do if it sent back a table (or multiple items)? Again, maybe an historical "feature" of earlier Lua versions of its C interface??????

((and stay tuned for an update to HS_Shape in a couple of months time -- it uses some of the "function vs table" ideas for sub-tool control -- the idea is to make it easier and more straightforward to add new sub-tools.))

[Rai López]

1. ScriptName

...the "LM_AddBone = {}" etc. is just a table assignment, which becomes significant when associated with the relevant script object in the repository. Without ScriptName it would be difficult to determine that this table was the actual script name...

Yes, it makes sense Moho has to do some kind of association/binding between Moho internals and the Lua code, and ScriptName seems the way to do it because there is nothing else in the script that could do it since, as you say, everything else are just assignments, callings and all... So I'm afraid that's all we can deduce, isn't? I mean, I think I was curious about if couldn't be something behind that very first process I could learn related to OOP and why Moho tools are designed the way they are, but maybe want to know beyond that point is something none of us are not going to need in practice when it comes to scripting and it may not worth the effort anyway...

2. Method() vs .property?

...So function calls offer a level of value protection (even though you can override the functions). I read that there are ways to make variables/tables read-only but involves messing with metaTables and other funky stuff.

That's one possibility I thought, but it's good to know what more experienced voices can say about your mere conjectures... Oh, I remember I also read about read-only variables long time ago when I can't remember what for) I needed a constant variable, it seems it can be natively done now in Lua 5.4, so we may have such feature at some point. Yeah, metatables are indeed funky , I've been watching some good tutorials about them and I thought start implementing them somehow should they bring some advantage of course, but it's kind of difficult for me to think where they can really contribute to get something you couldn't get by any other Lua regular mean... I'm right thinking that maybe metatables are simply more useful at other programming levels (like when making interactions with C and so) and therefore they make less sense from a scripter POV? The fact of there is no trace of them in any Moho script that I know somehow tends to force me to make that assumption, but of course I could be wrong...

...Moho "core" is written in C, and it's likely easier to call a function than to access a Lua Global.

That's something about I also mulled over at some point as well, that maybe it's easy (or simply more convenient for whatever technical reason) to deal with functions returning a value than with simple global variables or table entries.

((and stay tuned for an update to HS_Shape in a couple of months time -- it uses some of the "function vs table" ideas for sub-tool control -- the idea is to make it easier and more straightforward to add new sub-tools.))

You don't say... Very excited about what you can do with your experience and knowledge about Lua ins and outs! From my part I'm after getting something similar but with layer scripts in mind instead, I'm conscious it'll take time and in my case I may be simply pointing too high , but it's been exciting so far, plus it's proving to be good for keeping the mind occupied.

Well, thank you both for taking the time of replying and helping me on the way of trying to understand all this!