Naming issues

[GameMonetize]

For future version of babylon.js, I'm starting thinking about (PERHAPS) renaming illogical functions or properties.

If you think a function or a parameter is miss-labeled could you please respond to this post?

 

PS: I'm sure Wingnut will be happy to see this post.

PS': If you can argue why a name is not good this will be better

PS'': Please avoid off-topic stuff

[Wingnut]

hehe.  Actually, I am pretty happy with the naming issues, for once (rare treat).    Thanks for the PM's and discussions, DK and others.  I need to learn more, too. I wish I was smarter.  (sigh)  Thanks to ALL the forum people for helping to make me smarter, and for being tolerant of my big mouth, bad comedy, clumsy walking, and lack of knowledge.  I love all you guys and gals.

 

Let's talk a little about the scene get-By things.  I mean...  scene.getXXXByYYY()

 

-------------------

First, we need to think about... when should XXX... be plural?  Ever?  Never?  In DOM, getElementById()... 'Element' is not plural.  It returns one thing.

 

With DOM getElementsByTagName...  XXX is plural.  This returns a collection... which we can also call an array for our purposes.  So, for all the XXX  'things' we need to 'get'... will any need to be plural and return a collection/array? 

 

As a last note, notice that DOM uses 'Id' and we use 'ID'.  Wise?  I don't know.

 

------------------

Somewhere in this thread, let's talk about all the current and future XXX. Let's call them... groups.  We could call them 'collections' too, but that might confuse us with collections that could be returned, if we use plurals in the future.  Currently, our list of XXX groups include:

 

LastEntry (ByID)

 

LastMesh (ByID)

Mesh (ByID)

Mesh (ByName)

 

LastSkeleton (ByID)

Skeleton (ByID)

Skeleton (ByName)

 

Light (ByID)

 

Material (ByID)

Material (ByName)

 

This list is long, (and so is this post). There are no plurals in this group of get-by's.  But the Tags system DOES use plurals.  Keep reading.

 

I typed this list... so we could think about things. Does anyone think other groups will join this list?  Groups like Sprite, ParticleSystem, Bone, Texture, Collider, Polygon, Layer, Octree, ShadowGenerator, Viewport, Submesh, or even SubCanvas (for getting a virtual joystick or other canvas-overlay item). 

 

I don't know if subMeshes and sprites have names/ID's, or not.  I am too new at this to know.  Will we ever want to... scene.get... from the groups that I listed in the previous paragraph? 

 

That is a look into our GET-future, maybe.  The expanding world of XXX (groups).

 

-----------------------------------

Now let's talk about YYY.  We could call YYY... 'keys'.  Currently, we have two main YYY keys, and one new key:

 

Name (getXXXByName)

ID (getXXXByID)

Tags - NEW...

 

There appears to be 4 primary get-By's for the Tags system...

 

scene.getMeshesByTags(tagsQuery)
scene.getCamerasByTags(tagsQuery)

scene.getLightsByTags = function (tagsQuery)

scene.getMaterialByTags(tagsQuery)

 

(The last one should likely be pluralized...  getMaterialsByTags)

 

These methods are not listed on our API for the scene class, yet.  Our API documentation is at 1.9.0 and below.

 

[Gwenael, I did an edit here.  This is where the quote that Gwenael used in his following post... WAS at.] 

 

The TAGs system is the first get-by to use plural XXX.  It uses plurals in YYY, too.  Plural groups and plural keys.  WOW!  Power search!

 

---------------------------------

Just something to think about.  There was talk about TOOLS, too. The tags system currently lives in the Tools folder, but its four primary get-By's reside on scene. 

 

I am making no point, here.  I am simply 'stirring the pot' so our brains can think about our future.    Groups and keys, groups and keys.  The fun world of Get-By's. 

 

Be well, gang!  Thanks for the interesting new thread topic... which I instantly went off-topic from.    I'll wrangle this back into alignment. 

 

Does anyone know-of function or property names that could or should be changed, and do you have reasons why?  Talk about them in this thread, as wanted.  (there, re-aligned) 

[gwenael]

The TAG key MIGHT be the first key to use a plural XXX.  There was some talk about scene.getXXXsByTag - plural - returning a collection or array.  I don't know where we will go on that.  And maybe even ByTag(s).  Look out.  Plural groups and plural keys.  WOW!

 

 

yeah, I won

[Kilombo]

Good evening.

 

Although I agree with most of what Wingnut said. My opinion is that, those kind of syntax transformations can become a big issue to the evolution of Babylon community.

Babylon.js is a new project. New projects need stabilty to grow. The development of new functionality is always welcome. But when you speak of changing syntax or make a revolution in the way that you instantiate or call current methods/functions/classes, I really think that you are taking a big risk. It can kill the baby.

I think that renaming is not a real issue right now. Everyday someone finds a bug, everyday there's a new functionality needed. And I think that by investing time in those issues is what will bring maturity to the framework, and with that a bigger and stronger community.

 

Don't get it wrong ok, it's just my opinion (it worths what it whorts, no big deal).

[Wingnut]

Good points, K, and I agree, when approached from a "hurry to maturity" angle.  But one could ask one's self... "Am I in a hurry to mature?" and if so, "why?".  "Am I racing something?"  "Do I need or want to be racing something?". 

 

Sometimes, if we don't "adjust" what looks like "little faults in the baby", they mature into being big faults in the adult.  And they are very difficult to change... in long-established things.  They are much easier to change while still young.  That's just another way of looking at it.  Not necessarily right or wrong.

 

I really didn't propose anything in my previous post.  I just showed us where we are at, and where we could be going.  I am not sure that there IS a right or wrong way to do these things.  I DO think that racing or hurrying to maturity is an attitude that is programmed into us to some degree, and that ITS necessity needs to be questioned.  Do we need to hurry or race?  Are we hurrying?  And the most-ugly question of all... "Are we being pushed-around by Microsoft, indirectly?"

 

And then a person might want to ask one's self... "Is it wise to do any large projects with this framework... at this point in its maturity?"  Many of you notice that I don't do large projects.  Right now, not just is the framework changing, but MANY things around the framework are changing. 

 

One might ponder if it is a "sit back and watch" time, and not a time to lock into any particular way of doing things.  Maybe... stay liquid and flexible right now, and don't make promises.  Yes, that can cause slow maturing, but should we care about slow maturing?  Are we hurrying to become adult?  Should we be?  *shrug* 

 

Just thoughts.  Likely off-topic.  Thanks for your thoughts/opinions, Kilombo.  Keep them coming.  They certainly have solid merit, when looking at things from a certain angle.

 

Dad72, I'd love to hear from you, on this.  You are doing a very big project, as best I can tell.  Your unique view on this, would be interesting.

 

And I know that backward compat is a very high priority for deltakosh, but I don't know why.  He says that there are large projects using BJS, but he cannot tell us what they are, yet.  Do large projects put handcuffs on us and keep us from making changes to the baby?  *shrug*  It seems difficult to determine these things.

 

Are we going off-topic?  ("No, YOU are going off-topic, Mister Wingnut!")  

 

Deltakosh didn't ask for our (my) philosophies on evolution.  hehe.  Property and method names (and ways of doing things)... seem very related to 'evolution', though. Dk, might as well rename the topic to "Naming Issues and Desired Evolutionary Philosophies"  heh.  (just kidding)  (sorry if I am/we are... ruining the thread)

[gwenael]

I have to agree with both of you, Kilombo and Wingnut. I share your arguments. I would love that things stay as they are but I like when things are consistent too. If it's possible, even if the name is not totally correct in English (except wrong spelling of course), I wouldn't rename variables except if it's not consistent: for example sometimes it's spelled "color" and other times "colour", both are correct but it's not consistent. Let's take another example (not necessarily from current code either): "isEnabled" and "enabled" are both correct for me and both make sense but it's confusing for a developper since he never remembers what the name of variable is. Hopefully intelisence with Typescript will help on that.

[Dad72]

Dad72, I'd love to hear from you, on this.  You are doing a very big project, as best I can tell.  Your unique view on this, would be interesting.

 

 

I did not quite understand what you want to hear me ? If you mean to do a big project, it's embarrassing any changes babylon? Sorry if I have not understood everything.

Babylon for me need not necessarily rename functions, it does not bother me.

Whether a name or other name, I adapt. my requirements are more about the features rather than function names. well on a coherent function name is an asset for good grip.

[GameMonetize]

I must admit I feel more like kilombo

[Wingnut]

hehe.  I don't understand why people think this is a debate between two or more opposing "sides".  I didn't take a side. 

 

Ok, lets try it THIS way.

 

Continuing on current course, there will MAYBE soon be...

 

scene.getSpriteManagerByName/ID/Tags  (3 added funcs to scene)

 

and maybe soon...

 

scene.getShadowGeneratorByName/ID/Tags  (3 added funcs to scene)

 

and maybe soon...

 

scene.getParticleSystemByName/ID/Tags  (3 added funcs to scene)

 

And maybe lots more.  (Texture, Collider, Polygon, Layer, Octree, Viewport, Submesh, SubCanvas)

 

Its called "creaping featurism".  'Scene' could drown in get-Bys   I am not taking sides!  I just want us all (mostly the 'steering committee') to think about this.

 

There is another option: 

 

BABYLON.Query(scene, mesh, name, "sphere1");

BABYLON.Query(scene, light, id, "west*");

etc.

 

This would remove ALL get-Bys... from scene.  Just a thought.  Not taking any sides.    Scene object would then stablize, and Query object could expand until it explodes, as wanted.  Query object is called a 'proxy', I think.

 

And yes, Dad72, "I adapt" was the part I was interested-in.  I wanted to check if you had fear of doing a big project on a young framework, and if you had fear of changes that could make you do lots of repair work on your project.  thx.

[demonixis]

BABYLON.Query is a good way for me and avoid all methods getByXYZ. It's better for maintenance too but it may be less efficient instead of a classic getter..

 

Another way is to create an extension to BABYLON.Scene (BABYLON.Scene.extends.js) and add new prototypes in this extension (aka C# extensions). User can load this extension or not and it's easy to maintain

[Dad72]

Function QUERY who would replace any getByXXX :

 

PS:  Missing this function all the "getLastXXX"

// Getter functionScene.prototype.QUERY = function (searchBy, myObject) {	if(searchBy == "name")	{	    for (var index = 0; index < myObject.length; index++) {                if (myObject[index].name === searchBy) {                    return myObject[index];                }            }            return null;	}	else if(searchBy == "id")        {	    for (var index = 0; index < myObject.length; index++) {                if (myObject[index].id === searchBy) {                    return myObject[index];                }            }            return null;	}        else if(searchBy == "tag")        {             // ???        } };// UseBABYLON.scene.QUERY("name", mesh);//OrBABYLON.scene.QUERY("id", mesh);//OrBABYLON.scene.QUERY("tag", mesh);

 

This function may be added in addition of others existing (getBy). The user would use the one preferred.

[Wingnut]

@dad72 - I think your code is missing scene.meshes and a way to enter "sphere1".  I think the objective is to search all of scene.meshes for an object with name="sphere1", or id="sphere1", or "sphere1" in someobject.tags.  Maybe you had something else in mind.

 

To clarify, I did not mean to say that name, id, and tags should be done in one search, of course. 

 

Could be something like:

 

query(scene.meshes, name, "sphere1)

   or maybe

query(scene.lights, tag, "spotlight*")

   or maybe

query(engine.scenes, id, 12);  (getting ridiculous now) 

 

@demonixis - I suspect you are correct about less efficient.  Always trade-offs, eh?  Deltakosh talked with me about trade-offs once before.  I think I was proposing the same "consolidation" as this.     Sorry if I am rehashing. 

 

Again, I am not taking sides.    I am not JS-smart enough to make any decisions on these things. I just want us to think about possible future getter infestations.  Many people think it is too late to consider these changes/additions.  Maybe they are correct.

[Dad72]

I do not understand what you expect then. My sample code search for a mesh, a camera, a light, materials on the scene with a single function by id or by name. It's not what you ask?

[Wingnut]

@dad72 - To be honest, I do not know what your code is doing.  It looks like it is searching across a single object, to find its name, id, or tag.  I/We are talking about searching across all of scene.meshes array... to find and return an object with a name="sphere1" (or other search string).  I apologize if I am not understanding or if I am communicating poorly.  My "too much talk" gets in the way sometimes. 

[Dad72]

OK,I understand now. Yes my code search just an object, and not several. But gwenael to made a function "tags" to find several objects of a same tags. The id and name its done to be unique.

[Wingnut]

Cool.

 

What we are really thinking about now... is the future.

 

In the future, what if we need...

 

scene.getShadowGeneratorByName/ID/Tag

  and

scene.getParticleSystemByName/ID/Tag

  etc. etc.

 

The question is... will we add TOO MANY getters on the scene object... in the future?  MAYBE if we make a query engine...  we can remove all getters from scene (and not add any more), and instead use the query engine to do ALL getter activity FOR scene.  It will be a helper object... that can search scene.meshes, scene.lights, scene.cameras, engine.scenes, all sorts of searches... across all sorts of arrays and collections.

 

Maybe we don't remove the current getters from scene object, but still make a query engine.  Gwenael's tags query system... is ready for more action... and built to take abuse. It is strong enough to search for more things than just tags.  I bet it can find Easter eggs, and maybe even gold.   

 

Just thinkings and talkings. 

[demonixis]

@dad72 We can simplify a bit this code by this one :

 

Babylon.Scene.Query = function (searchBy, myObject) {    if (myObject.length) {        for (var i = 0, l = myObject.length; i < l; i++) {            if (myObject[i][searchBy] === searchBy) {                return myObject[i];            }        }    }    return null;};// UseBABYLON.scene.Query("name", meshes);//OrBABYLON.scene.Query("id", meshes);//OrBABYLON.scene.Query("tag", meshes);

But once again, I don't think that is really efficient.. IMHO an extension is the best way to have extra getters/setters.

[GameMonetize]

I'm not against a query engine but for the sake of performance we must also keep some basic and direct getter

[Wingnut]

Ok, moving right along... 

 

Does anyone else have any thoughts about arcRotateCamera.wheelPrecision...  being reversed, and then being named .wheelSensibility?  Currently, the higher the number, the more "precise" the wheel works (the slower the .radius change)... properly done per its name.

 

If it were changed to .wheelSensibility, its value would need to be reversed...  the higher the number, the faster the change to .radius.

 

Just a thought.  We use .angularSensibility and .moveSensibility on some of our other cameras.  *shrug*  Not taking sides.  (Wingnut wears his hard hat for safety reasons.) 

[Wingnut]

Ok, how about... particleSystem...  .manualEmitCount and .targetStopDuration ?

 

They COULD become...  .count and .duration.  Or maybe better... .manualCount and .manualDuration .

 

They are related.  *shrug*

 

I wonder... why does .manualEmitCount default to -1, and .targetStopDuration default to 0 ?  Could they both become the same?

 

Just thoughts.  Wingnut being annoying... what's new? 

[GameMonetize]

They are not the same:

- manualEmitCount is the number of particles to emit and then stop (The system will continue to live but will not emit more particles)

- targetStopDuration is the life duration of the system.(after the given duration the system will be killed)

[Wingnut]

ahh... ok thanks!  I was thinking that targetStopDuration was the amount of seconds of emitting.  I should have tested and looked at the code before talking.