Hi Bruce!
The short answer is Yes, the default settings do not enable void safety
in 6.4.
To enable void safety checking and standard syntax in your code, go to
the project settings dialog.
Under Groups/Clusters, select your root cluster. In the General
section, you will see "Void safety". Select that and choose "Complete
Void Safety". Also set "Are types attached by default?" to True. While
you're at it, select, under Syntax, "Standard Syntax" if you're ready to
take the plunge, or "Transitional Syntax" if you're not quite ready to
jump (I say go for it).
I enable Full Class Chacking while I'm at it.
You will also have to change the paths for your base (or other)
libraries and precomps to the "-safe" versions (under Groups/Libraries
and Groups/Precompile). For example, your Location field for base is
probably "$ISE_LIBRARY\library\base\base.ecf" or equivalent. Change
that to "$ISE_LIBRARY\library\base\base-safe.ecf" or equivalent. Do the
same for other libraries and precompiles where there are different
versions. Do not attempt to change the "Are types attached by
default?", "Void safety" or "Syntax" fields for libraries and
precompiles, as their respective ecf files already set those values.
What I did was to make 2 projects: one original and one void safe, with
different config files but common (personal) sources. I created
subdirectories for legacy and void-safe variants of my source and tried
building each.
The legacy should build correctly unless you have some very very old
code. Then start working on the void-safe version, with a new project
and brand new ecf file. I find it easy enough to clone-and-edit the
original ecf file to make a void safe one, at least to start, then let
the config dialog take over, but I can see how the config dialog might
be the preferred mechanism.
You might have a couple of false starts that will require blowing away
your EIFGENs after a brain transplant in the ecf file, but you'll
converge quickly.
Depending on the complexity of your code, you might actually be able to
build your application with void safe base and other libs, but leaving
your clusters w/ void safety off. This can be handy for getting
something to work with (the libs and precomps in place) before diving
into possibly massive edits on your stuff.
If you have multiple clusters, you might be able to tackle them one at a
time, or you might just want to dive in.
Be prepared to redo your changes after the first round. You will find
some patterns that you thought were right kind of falling out of favor
as you refine your converted code. You're likely to discover (let me
put this politely) some "legacy" patterns in your code that could use a
wholesale trip to the landfill. Of course, it's also possible that your
code is perfect.
One trick that helped me keep my code changes a little more under
control was to create a temporary 'shim' class for type/attachment
tests. A couple my clusters (printf in particular) used quite a bit of
assignment attempt. If yours don't, then it's not worth the effort.
The shim class had features like any_to_string_8, any_to_finite,
any_to_integer_32_ref and so forth. I created 2 such classes, one for
legacy and one for void-safe + standard syntax. The legacy version used
assignment attempts and the "modern" version used attachment test.
Eventually, this stuff will be replaced with the long promised multi-way
type check.
In the client code, I would replace assignment attempts with calls like:
my_any: ANY
...
ts := any_to_string_8 (my_any)
if ts /= Void then
...
In the legacy client code, I had locals of the form:
local
ts: STRING_8
and in the void-safe/standard client code, my locals looked like this:
local
ts: detachable STRING_8
This helped me quite a bit when working with assignment attempt dense
code because the new and old code then differed only by the detachable
keywords. It is worth noting that I was trying to make the old code
work with 6.2 for backward compatiblity reasons.
For 6.4, I could have opted for standard syntax w/o void safety, but I
figured why bother? I built versions in 6.4 for obsolete syntax (for
comparison and testing against the 6.2 version), and for void-safe +
standard syntax (aka fully modern). It was a bit of extra work (nothing
brain-taxing), but it let me do side-by-side comparisons with smaller,
well understood changes. You probably don't want to go through the
extra trouble.
R
==================================================
Roger F. Osmond
> -------- Original Message --------
> Subject: [eiffel_software] Do I need to explicitly turn void-safety on?
> From: "brucemount" <
[hidden email]>
> Date: Sun, August 09, 2009 12:15 pm
> To:
[hidden email]
> I've read many (but not all) of the posting here about trouble converting to void-safety. I read the doc pages on eiffel.com, downloaded 6.4, and braced myself for my first void-safe compile.
> ....and my current project compiled and ran first time....uh, which makes me think I'm doing something wrong. My old project is most definitely not void-safe, and I use Gobo a lot, which I thought was not yet void safe, so I was expecting compiler message.
> Is there some switch I need to flip to turn on void-safety? Is this running in some kind of backwards compatibility mode?
> Thanks,
> --Bruce
