Hi,
While working towards void-safety of EiffelBase I encountered
the following issue with *STRING* classes. The features
`make_from_string' and `make_from_c' are used both as
creation procedures and normal features that initialize an existing
object. In the latter case they access the attribute `area'
to see if it has to be adjusted to hold the new data. However
when the features are checked as creation procedures the
access to `area' is reported as erroneous, because the attribute
is not set yet.
We have the following options to address the issue:
1. Abandon adaptation of void-safe variant of FreeELKS based on
the existing class interface. I'd prefer to avoid this scenario
as EiffelStudio moves towards void-safe Eiffel as described
in the ISO/ECMA standard, so creating a new branch of divergence
is not that attractive.
2. Introduce a new rule that would allow to access attributes
if this is done to check if the value is void or not, for example
{a: ANY} area
or
area /= Void
can be accepted even if `area' is not set. Probably it would work,
but creating/modifying a validity rule to cover this particular case
of FreeELKS is not that great, as makes an exception in otherwise
working set of rules only to address the tiny issue.
3. Mark the features as obsolete in the existing classes and add
a pair of new features for `make_from_c' and a pair for
`make_from_string': one would be a creation procedure, the other one
- a normal routine. They would not suffer from the issue with accessing
a non-initialized attribute. Then we can create the new classes with the
new features and without the old ones. If one uses non-void-safe
code, he can use the old classes, but will be warned about the use
of old features, so he can update the existing code to the new
interface. If one uses void-safe code, he will use the new classes that
do not have void-safety issues.
I would propose to use the option 3 and adopt the following migration plan:
1. Introduce a pair of new features for `make_from_string' and `make_from_c',
one will be a creation procedure, the other one - initialization routine for the
existing object.
2. Mark `make_from_string' and `make_from_c' as obsolete and specify
which features should be used instead.
3. Add void-safe classes without the features `make_from_string' and
`make_from_c'. Initially this can be done outside of FreeELKS repository,
so that there is no confusion.
Comments are welcome,
Alexander Kogtenkov
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
