Enumerated class skeleton
Please find attached a skeleton class for enumerated type. By default, I push this class to utility library.
I'm not sure I understand how this class can be useful. How is it modelling an enumerated type? How does it enforce that the enumerated type is only made up of a well known set of objects and that no one can create other instances of this type?
As for where this class belongs, I would rather say that it should go to the pattern library.
Below, a simple example of how to use this skeleton :
frozen expanded class SAMPLE
inherit
UT_ENUM [NATURAL]
create
make
feature
-- Types
one : NATURAL = 1
two: NATURAL = 2
feature {}
members: DS_SET [NATURAL]
once
Result := create {DS_SET}.make(<<one, two>>)
end
end
Assertions must be activated.
About assertions, as I mentioned before, gec tries to generate optimized code, so it does not generate assertions at all, even when specified in the Xace file. Assertions will be added in the future...
About the syntax error, gec will try to compile only what will end up in the final executable. This makes the compilation much faster. Since assertions are not supported in the final executable yet, they are not compiled. If you want to see the syntax error, you should use gelint instead of gec.
Okay, I will check all my pull requests this evening.
In your SAMPLE class, it should be:
Result := create {DS_HASH_SET [NATURAL]}.make (<<one, two>>)
and not:
Result := create {DS_SET}.make(<<one, two>>)
Also, your skeleton class says that members is an ARRAY and calls contains on it. There is no such routine in ARRAY. And now your example says that members is a DS_SET. But this class does not inherit from ARRAY.
The problem with the design of the skeleton class is that when calling make the client does not know what are the valid values for the argument being passed. Calling:
create {SAMPLE}.make (3)
and waiting for the invariant to get violated is not in the spirit of Design By Contract. An invariant violation means that there is a bug in the class containing the invariant (here SAMPLE), not in the client using this class. The client should be able to verify that the SAMPLE object it will create will be valid before actually creating it.
If this can be useful for you, here is how I work:
- I use ISE EiffelStudio IDE to work on my project. It allows be to use its debugger, etc.
- Then I compile it with
gecto get optimized executable. - The use of
gelintcan also find problems not found by EiffelStudio. - And finally I run the Gobo test suite both with
gecand ISE'secto make sure that the code in the Gobo package compiles and work with both Eiffel compilers. Ideally, this last step should be performed by a continuous integration system like Jenkins or TeamCity (cross Eiffel compilers and cross platforms), but I didn't find yet a free site on the internet hosting such system. I didn't look that much though, so if someone has suggestions, they are welcome.
Yes I'm working only with Gobo and a small basic text editor... not very convenient. I will install EiffelStudio and check all my codes.
Concerning CIs, I use Jenkins for Java & Node.JS projects. But I've also used Travis with GitHub (e.g of integration with GitHub: https://github.com/z0mt3c/node-restify-validation).
It is possible to add Eiffel language to Travis though this process at this URL
I pulled the modification made in .gitattributes about source code "E" not recognized as Eiffel. I'm waiting for the enum class to be improved before considering pulling it to the main branch.