Cosmetics and small refactoring

[telephon]

• no need to make class methods here
• move assets to a better place
• and just some formatting

[capital-G]

• no need to make class methods here

In other languages its best practice to make use of static methods as much as possible if they are deterministic because they can not modify the object (and there is a neglectable speed boost)

• no need to make them private

I consider them a perfect example of something that should be private static method - they are of no concern to the actual test as they are internal, deterministic helper methods and should therefore not be exposed in autocompletion or docs.

---

I currently find the path layout rather confusing as the test files are at a different location (why is this a convention in SC? makes mirroring folder layouts necessary on bigger projects - java does this but this is due to their namespacing rules on filenames which SC does not have).
the asset files for the test yet remain in the classes folder.

[telephon]

I consider them a perfect example of something that should be private static method

Hm, yes, from a java perspective probably true.

But in sclang it is rather unidiomatic to do it like this, because you always have to go through an extra indirection if you want to call the method from an instance ( this.class.something )

Private methods are really only those which you can't or shouldn't call from outside because of a technical condition. They don't read that well, usually there is a wrapper for them that "speaks" better.

If you like to make them private, put them in a section at the end of the class definition. That way they are not obscuring the more important things.

[capital-G]

But in sclang it is rather unidiomatic to do it like this, because you always have to go through an extra indirection if you want to call the method from an instance ( this.class.something )

oh, now I remember. Something for the SC4 backlog as well :)

If you like to make them private, put them in a section at the end of the class definition. That way they are not obscuring the more important things.

To me its less about the source code but about the interface you provide - on test this is probably neglectable but in general it helps to understand what is happening in a quick manner w/o lurking into source-code/docs/method-scrolling by relying more on autocomplete/object inspection. Having a concise exposed interface, good naming of methods/args and have their expected (return) types transparent makes coding so much more comfortable - but I am not too sure that SC is all about make coding easy :D

Some things I think should be changed are

• the location of the JSON files (which are test assets) and
• dirname.dirname - calling dirname of a diraname results in going one dir up? can't we use something which is more obvious/standardized when working with paths such as ../ (if it works on unix/windows environment?)
• more consistency on directory cases
  

[telephon]

• dirname.dirname - calling dirname of a diraname results in going one dir up?

yes, what else? :)

The rest of the discussion (about private and class methods) we should have somewhere separately.

[capital-G]

yes, what else? :)

I would assume that the dirname of a directory would be the dirname itself, so identity?

[telephon]

ah I see! I read "the directory of a directory"
Or also: "the dirname X of a directory is the dirname X", but "the dirname X of a dirname Y is not Y itself"