API Change suggestion: removeAll->removeAllChildren

[MasterGod]

I think having Just the docs saying it removes all the children is not enough and removeAll() by itself isn't that informative about what it really does.
I believe changing removeAll() to removeAllChildren() would be more friendly and informative about what the method is doing IMHO.

Now I know you guys hate API changes but Edit->Find and Replace: removeAll(); with removeAllChildren(); pretty much solves it.

[sp00n]

it hasn't sence, 'cause in C++ very rarely used object-self-destructing methods, and many coders know it, so when they see a RemoveAll() method they know that is RemoveAllChildren() (or similar) and vise versa self-destructing method will be called somehow especialy for that you use it very carefuly

[rogerborg]

I agree with the above.

If you're left wondering which post I'm agreeing with, then perhaps that illustrates why unambiguity is useful.

[xDan]

since children is plural it could be removeChildren(), that would get my vote.

[JP]

Now I know you guys hate API changes but Edit->Find and Replace: removeAll(); with removeAllChildren(); pretty much solves it.

it's not just a case of having to go through all the code and change the function name from removeAll to removeAllChildren...

When you change a function name it breaks the API so that if you want to update your code with a new version of the library it won't compile, you'll have to find out which function names have changed and then go through and change them all.

A good example of this is when the IEventReceiver onEvent function's parameters changed from 'SEvent' to 'const SEvent&' when going from 1.3.1 to 1.4. That's caused a lot of posts on the forum by confused people!

[Halifax]

Now I know you guys hate API changes but Edit->Find and Replace: removeAll(); with removeAllChildren(); pretty much solves it.

it's not just a case of having to go through all the code and change the function name from removeAll to removeAllChildren...

When you change a function name it breaks the API so that if you want to update your code with a new version of the library it won't compile, you'll have to find out which function names have changed and then go through and change them all.

A good example of this is when the IEventReceiver onEvent function's parameters changed from 'SEvent' to 'const SEvent&' when going from 1.3.1 to 1.4. That's caused a lot of posts on the forum by confused people!

Yeah, I have to agree. And there is no need to increase the version number for this minute and insignificant naming scheme. As JP said, it will just increase the post of confused newcomers.

I think it is fine as it stands.

[Virion]

I think it's because the tutorials had never been updated hence causing confusion to the newcomers.

[JP]

That's true, the tutorials on the webpage still have addTestSceneNode i think, they really need to either be removed (they're fairly pointless as the tutorials are provided in the SDK anyway, just keep the non-SDK tutorials up there, but up to date) or update with every SDK release.

But still, it's not just n00bs who get confused when the webpage tutorials don't compile, it's people updating their projects, sure if they're experienced programmers they should be able to understand what the error means and notice that there's probably been an API change but not everyone using irrlicht is that experienced!

[Halifax]

That's true, the tutorials on the webpage still have addTestSceneNode i think, they really need to either be removed (they're fairly pointless as the tutorials are provided in the SDK anyway, just keep the non-SDK tutorials up there, but up to date) or update with every SDK release.

But still, it's not just n00bs who get confused when the webpage tutorials don't compile, it's people updating their projects, sure if they're experienced programmers they should be able to understand what the error means and notice that there's probably been an API change but not everyone using irrlicht is that experienced!

I have to agree with that. But I don't agree with completely removing the tutorials from the homepage as they are a "selling point" of Irrlicht. Once the person decides to use Irrlicht, and downloads the SDK, then they should use the SDK tutorials, and not the site. I'm sure lots of people do that, I have never used the site tutorials, but did in fact look at them when I was first deciding to use Irrlicht some time ago.

[vitek]

On a related note, does Irrlicht have a written versioning policy?

Lots of open source projects don't allow source incompatible changes until a major version change. Such releases do not happen very often.

Travis

[rogerborg]

But still, it's not just n00bs who get confused when the webpage tutorials don't compile, it's people updating their projects, sure if they're experienced programmers they should be able to understand what the error means and notice that there's probably been an API change but not everyone using irrlicht is that experienced!

Suffering builds character.

[JP]

No tears please... it's a waste of good suffering....

And so this post isn't just complete spam, i do agree, you have to plough through a load of poop to actually learn and grow as a programmer!

[MasterGod]

Suffering builds character.

Then I guess you've suffered a Lot

[hybrid]

On a related note, does Irrlicht have a written versioning policy?

Lots of open source projects don't allow source incompatible changes until a major version change. Such releases do not happen very often.

We do have incompatible changes in the minor releases also. Beginning with Irrlicht 1.4 I try to keep the patch levels free from incompatible API changes, i.e. 1.4.1 should update without problems, while 1.5 might (will) have incompatible changes.