Re: references: backwards compatibility
Dominique Devienne wrote:
Ok, I will get my id reference stuff ready.
I do not think that we need a commandline arg or a property, the
only thing that is needed is a warning like DD's
Warning: Reference y has not been set at runtime, but was found during
build file parsing, attempting to resolve. Future versions of Ant may
support
referencing ids defined in non-executed targets.
I'm confused... Are you saying we'll leave the loophole of accessing
refs from non-executed targets, and just print a warning?
Ant should fail by default in this situation. If someone wants to run
in full BC mode, perpetuating the old broken ref handling, they *must*
explicitly say so to Ant, and it should not be the default mode. Since
Steve says he doesn't want to fix these other builds, then it has to
be something specified out the build, use a CLI switch or the setting
of a user property as proposed by Stefan.
BC is important to me, but when keeping BC means breaking my least
surprises motto, then BC is not my friend any more ;-) --DD
Since the change went in, I found three build files of mine that were
broken. All of these were the erroneous
1. two cut and pastes of some code to evaluate and print a reference (I
should macro it, I know, but then I'd need :-
** HERE **
level="verbose">compile.classpath=${compile.classpath.value}
As this was just an echo, it was an error, but a harmless one. The fix
2. one build file had a target that had incomplete dependency ordering,
and which really broke. I needed to add a depends target to get it to build.
Both of these were IMO bugs, and neither of these bugs would have been
found without the recent changes. So, I think the changes were good
-they found and fixed bugs in my code.
But a 'bug' that has existed for a long time, it can become a feature.
And, for problem #2 above, until I fixed the build file, the project did
work correctly. I had an implicit dependency on the bug.
I am all +1 for the change, and happy to fix my own build files. I just
dont want people downstream to have to fix them for me. Which is what
will happen whenever someone out there does try and take a shipping
smartfrog source distro and rebuild it on ant1.7 beta 3. And you know
who they will complain to, dont you? Me :)
This is why I am +1 for Peter's fix of a fallback state with a big
warning message. it is a bug, but one that can be hard coded into
projects. We should print out the message then point people at a wiki
page covering the details and the actions
-do nothing: have your app break in future. If the build file is not
yours, this is your first choice
-fix the reference to point to a valid reference (i.e. defect #1 above)
-get your dependencies right (#2)
Incidentally, on the topic of 'no to expansion of non-defined
properties'. What, even in echo?
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On Tue, 17 October, 2006 5:24 pm, Dominique Devienne wrote: >> > BC is important to me, but when keeping BC means breaking my least >> > surprises motto, then BC is not my friend any more ;-) --DD >> >> I am afraid that ant has a lot of surprises! > > And this is bad. That's why Ant is difficult to use for large builds, > because the build becomes exponentially difficult to troubleshoot > when something goes wrong. > > I think we need to move toward a policy system where Ant's behavior > can be made safer and more deterministic, like forcing to fail on: > - not-runtime-defined references > - allow or not reference overriding > - expansion of non-defined properties > - allow or not the property immutability hole of Project.setProperty > - etc... This is the essence of "fail fast", and as a design philosophy, I think it will lead to much more robust software (or build scripts, in the case of Ant). I've lost count the number of times I've tracked down weird failures in Ant scripts that were really a result property not being defined further upstream. Fail fast in situations like these would really save me time. Cheers, -- Joe Schmetzer .:. Renaissance Developer .:. http://www.exubero.com/ +44-(0)7775-770-422 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
[...], a copy of the UE will be executed and the "real" object [...] I guess this is where the difference really is. The implementation on how the 'static' reference is resolve is now safer, yet at the user level, the behavior remains the same, with just a new warning thrown in. I wanted us to 'fix' it at the user-level. I can write a target which defines a property and an id'd fileset that depends on this property, so when it's resolve, the fileset will be 'correct' impl-wise but since the property is uses is not defined, because hasn't been executed, it's semantically wrong. The build will go on, and for example non pick up some files, because the property didn't expand in an . Sorry you get a warning now, which is better, but the point of where the build doesn't behaved as expected by the user might be very different from the point when the warning is issued, so easily ignored. In my experience, few people can read error messages, and even fewer read warnings... > BC is important to me, but when keeping BC means breaking my least > surprises motto, then BC is not my friend any more ;-) --DD I am afraid that ant has a lot of surprises! And this is bad. That's why Ant is difficult to use for large builds, because the build becomes exponentially difficult to troubleshoot when something goes wrong. I think we need to move toward a policy system where Ant's behavior can be made safer and more deterministic, like forcing to fail on: - not-runtime-defined references - allow or not reference overriding - expansion of non-defined properties - allow or not the property immutability hole of Project.setProperty - etc... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On 10/17/06, Dominique Devienne <[EMAIL PROTECTED]> wrote: > Ok, I will get my id reference stuff ready. > I do not think that we need a commandline arg or a property, the > only thing that is needed is a warning like DD's > > Warning: Reference y has not been set at runtime, but was found during > build file parsing, attempting to resolve. Future versions of Ant may support > referencing ids defined in non-executed targets. I'm confused... Are you saying we'll leave the loophole of accessing refs from non-executed targets, and just print a warning? Ant should fail by default in this situation. If someone wants to run in full BC mode, perpetuating the old broken ref handling, they *must* explicitly say so to Ant, and it should not be the default mode. Since Steve says he doesn't want to fix these other builds, then it has to be something specified out the build, use a CLI switch or the setting of a user property as proposed by Stefan. I am proposing not complete BC, it is more a fall-back behaviour, if a reference is requested *and* not found, then the id references are checked and if found there, a copy of the UE will be executed and the "real" object will be given to the caller along with an ugle warning explaining what is happening. This will mean that the reference bugs found in Ant 1.6.5 will be fixed (especially the ones triggered by
Re: references: backwards compatibility
Ok, I will get my id reference stuff ready. I do not think that we need a commandline arg or a property, the only thing that is needed is a warning like DD's Warning: Reference y has not been set at runtime, but was found during build file parsing, attempting to resolve. Future versions of Ant may support referencing ids defined in non-executed targets. I'm confused... Are you saying we'll leave the loophole of accessing refs from non-executed targets, and just print a warning? Ant should fail by default in this situation. If someone wants to run in full BC mode, perpetuating the old broken ref handling, they *must* explicitly say so to Ant, and it should not be the default mode. Since Steve says he doesn't want to fix these other builds, then it has to be something specified out the build, use a CLI switch or the setting of a user property as proposed by Stefan. BC is important to me, but when keeping BC means breaking my least surprises motto, then BC is not my friend any more ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
Peter Reilly wrote: On 10/17/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote: On Mon, 16 Oct 2006, Peter Reilly <[EMAIL PROTECTED]> wrote: > what do other people think? I'm with Steve here. We need a way to get around broken build files of projects you want to build but don't own. I don't care much whether it is a property (would be in line with other things we've introduced) or a command line argument - the later would need a way to propagate to started projects which you would get for free for user properties, though. Ok, I will get my id reference stuff ready. I do not think that we need a commandline arg or a property, the only thing that is needed is a warning like DD's Warning: Reference y has not been set at runtime, but was found during build file parsing, attempting to resolve. Future versions of Ant may support referencing ids defined in non-executed targets. +1 the error should include a URL to a wiki entry on the topic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On 10/17/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote: On Mon, 16 Oct 2006, Peter Reilly <[EMAIL PROTECTED]> wrote: > what do other people think? I'm with Steve here. We need a way to get around broken build files of projects you want to build but don't own. I don't care much whether it is a property (would be in line with other things we've introduced) or a command line argument - the later would need a way to propagate to started projects which you would get for free for user properties, though. Ok, I will get my id reference stuff ready. I do not think that we need a commandline arg or a property, the only thing that is needed is a warning like DD's Warning: Reference y has not been set at runtime, but was found during build file parsing, attempting to resolve. Future versions of Ant may support referencing ids defined in non-executed targets. Peter Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On Mon, 16 Oct 2006, Peter Reilly <[EMAIL PROTECTED]> wrote: > what do other people think? I'm with Steve here. We need a way to get around broken build files of projects you want to build but don't own. I don't care much whether it is a property (would be in line with other things we've introduced) or a command line argument - the later would need a way to propagate to started projects which you would get for free for user properties, though. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
I would make it a non-failing warning for ant1.7, maybe an error in 1.8. I can see where you are coming from, but I disagree on accepting the old build files, or at least not without a --keep-old-broken-behavior switch on the command line, instead of yet another magic property. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
Peter Reilly wrote: On 10/16/06, Dominique Devienne <[EMAIL PROTECTED]> wrote: > WARNING: reference y has not been set, attempting to resolve > > [echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml I really think we should break BC here, with a good error message. Keeping the old behavior would re-open the bug about the not-defined-at-runtime ref being used. The fact that there would now be a warning is not enough IMHO. For a first pass, I propose an error message along the lines of: Error: Reference y has not been set at runtime, but was found during build file parsing. Ant 1.7 no longer allows referencing ids defined in non-executed targets. This could be done, what do other people think? My biggest concern is how to ensure that ant1.7 builds build files that other people wrote. I dont want to have to edit random build.xml files created by third party projects I download and build, just because they (like me) got lazy. The fact that Ant has had a bad but stable way of declaring references mean that we need to think of how best to move people of it. I would make it a non-failing warning for ant1.7, maybe an error in 1.8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
Hi Dominique, this sounds like a good idea. Regards, Antoine Original-Nachricht Datum: Mon, 16 Oct 2006 09:58:58 -0500 Von: "Dominique Devienne" <[EMAIL PROTECTED]> An: "Ant Developers List" Betreff: Re: references: backwards compatibility > > WARNING: reference y has not been set, attempting to resolve > > > > [echo] y is C:\Documents and > Settings\reilly\learning\a\refs\build.xml > > I really think we should break BC here, with a good error message. > Keeping the old behavior would re-open the bug about the > not-defined-at-runtime ref being used. The fact that there would now > be a warning is not enough IMHO. > > For a first pass, I propose an error message along the lines of: > > Error: Reference y has not been set at runtime, but was found during > build file parsing. Ant 1.7 no longer allows referencing ids defined > in non-executed targets. > > --DD > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On 10/16/06, Dominique Devienne <[EMAIL PROTECTED]> wrote: > WARNING: reference y has not been set, attempting to resolve > > [echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml I really think we should break BC here, with a good error message. Keeping the old behavior would re-open the bug about the not-defined-at-runtime ref being used. The fact that there would now be a warning is not enough IMHO. For a first pass, I propose an error message along the lines of: Error: Reference y has not been set at runtime, but was found during build file parsing. Ant 1.7 no longer allows referencing ids defined in non-executed targets. This could be done, what do other people think? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
WARNING: reference y has not been set, attempting to resolve [echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml I really think we should break BC here, with a good error message. Keeping the old behavior would re-open the bug about the not-defined-at-runtime ref being used. The fact that there would now be a warning is not enough IMHO. For a first pass, I propose an error message along the lines of: Error: Reference y has not been set at runtime, but was found during build file parsing. Ant 1.7 no longer allows referencing ids defined in non-executed targets. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
On 10/16/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> I think some kind of property ant.policy.references.inline or something
> could be set to turn on old behaviour
We've somehow never done it, but maybe we should have a version
attribute on , and increment it whenever we introduce a BC
breaking change?
I'm not sure it's practical to provide both the old and new behavior
when Ant changes some fundametal. Imagine having to support 1.5-style
mix of parse-time and run-time element processing, instead of all UE a
la 1.6?
Something that we could do maybe in this case is gather at parse-time
a list of all ids, and on using an unknown id, consult this list, and
if finding a match, issue a more informative error message? Not great,
but keeping the old and new behavior, especially when the old one was
wrong, I'm not a bug fan of. --DD
I am at the moment working on a solution along this lines:
have an IdReferences that keeps track of the ids.
if an id cannot be resolved when using project.getReference(id),
check the id references and resolve it the old - fashioned way
with a warning:
y is ${myPath}
x:
WARNING: reference y has not been set, attempting to resolve
[echo] y is C:\Documents and Settings\reilly\learning\a\refs\build.xml
The code is simple, except for the usually silliness around <*ant*>
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: references: backwards compatibility
I think some kind of property ant.policy.references.inline or something could be set to turn on old behaviour We've somehow never done it, but maybe we should have a version attribute on , and increment it whenever we introduce a BC breaking change? I'm not sure it's practical to provide both the old and new behavior when Ant changes some fundametal. Imagine having to support 1.5-style mix of parse-time and run-time element processing, instead of all UE a la 1.6? Something that we could do maybe in this case is gather at parse-time a list of all ids, and on using an unknown id, consult this list, and if finding a match, issue a more informative error message? Not great, but keeping the old and new behavior, especially when the old one was wrong, I'm not a bug fan of. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Mon, 11 Apr 2005, Matt Benson > <[EMAIL PROTECTED]> wrote: > > > Ever noticed that every Ant type that supports the > > id/refid pattern must include a load of custom > code? > > Why? Wouldn't it be possible in UE to check all > > DataType subclass elements for refid, validate no > > other attributes/elements/nested text, and > substitute > > the actual object? > > Nobody says that anything in Ant with a refid needs > to extend DataType > at all. True, but that's about the only place where we have any kind of central handling for refid. I suppose in a perfect world refid should always be handled externally and tasks had better be reusable, or else can be marked as not supporting refid? -Matt > > Stefan > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
On Mon, 11 Apr 2005, Dominique Devienne <[EMAIL PROTECTED]> wrote: > So on second thought, it sounds doable. The only possible break of > BC I can foresee ATM would be for custom types, outside of Ant, > which broke the unwritten rule that no attributes/elements are > allowed once one uses refdid="someId", and I don't mind that ;-) Don't we break that ourselves? At least users want us to do something like and I don't know (without checking bugzilla) whether we've implemented or rejected that. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
On Mon, 11 Apr 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > Ever noticed that every Ant type that supports the > id/refid pattern must include a load of custom code? > Why? Wouldn't it be possible in UE to check all > DataType subclass elements for refid, validate no > other attributes/elements/nested text, and substitute > the actual object? Nobody says that anything in Ant with a refid needs to extend DataType at all. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
Matt Benson wrote: So the rule becomes, "when writing a custom type, IF you extend DataType, and IF those who program to your custom type only use addXXX and/or add(Type), then the refid attribute will be handled for you automatically." That's all well and good, but basically I don't see what it gains us. In a rewrite I think it would be possible to have everything a form of add() or addXXX(), the latter serving only to give a specific element name to an instantiable type. But given the responsibility of supporting all historical subelement creation patterns I don't see that reference processing in the core stops authors of new DataTypes (including us) having to support refid through code. I'd love to be wrong, though. No, you are right, I think. The processing of refs in the types themselves is unfortunate. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
--- Conor MacNeill <[EMAIL PROTECTED]> wrote: > I support moving reference processing into the core. > This is how mutant > worked. It is certainly a core responsibility. > > It should only be done for addXXX methods. By the > core-task contract > those are the elements for which the task has given > the core the > responsibility for creating the element instance. > For createXXX, the > task is saying that it is in control and it needs to > do its own refid > processing. So the rule becomes, "when writing a custom type, IF you extend DataType, and IF those who program to your custom type only use addXXX and/or add(Type), then the refid attribute will be handled for you automatically." That's all well and good, but basically I don't see what it gains us. In a rewrite I think it would be possible to have everything a form of add() or addXXX(), the latter serving only to give a specific element name to an instantiable type. But given the responsibility of supporting all historical subelement creation patterns I don't see that reference processing in the core stops authors of new DataTypes (including us) having to support refid through code. I'd love to be wrong, though. -Matt > > Conor > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: References
Matt Benson wrote: Ha, I think we've been stonewalled. What we're talking about is great for add* methods, but I think we're out of luck for create* methods. Although I never use these anymore either. Seems kind of bad to say "refid works on all datatypes automatically, unless you use createXXX methods"... :( I may keep messing around with this just to see what happens though. -Matt I support moving reference processing into the core. This is how mutant worked. It is certainly a core responsibility. It should only be done for addXXX methods. By the core-task contract those are the elements for which the task has given the core the responsibility for creating the element instance. For createXXX, the task is saying that it is in control and it needs to do its own refid processing. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: References
Ha, I think we've been stonewalled. What we're talking about is great for add* methods, but I think we're out of luck for create* methods. Although I never use these anymore either. Seems kind of bad to say "refid works on all datatypes automatically, unless you use createXXX methods"... :( I may keep messing around with this just to see what happens though. -Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: Matt Benson [mailto:[EMAIL PROTECTED] > > > > Hmm, from all your comments it seems you have > pointed > > out that the best solution would be for types to > have > > no knowledge whatsoever of refids. > > True. > > > Of course this is > > not possible under the gaze of the BC monster. We > > could always start the mythological Ant 2 after > 1.7 to > > apply the learning of the past several years. > I'll > > keep thinking about this, though. > > But assuming that the framework starts > unconditionally handling datatype > refids, then older code keeps on working just fine. > The old setRefid() > methods never get called (by the framework), and the > manual checks > succeed, while still catching erroneous programmatic > use of setRefid(). > New types just ignore refid altogether, and are > greatly simplified. > > So on second thought, it sounds doable. The only > possible break of BC I > can foresee ATM would be for custom types, outside > of Ant, which broke > the unwritten rule that no attributes/elements are > allowed once one uses > refdid="someId", and I don't mind that ;-) --DD > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: References
> From: Matt Benson [mailto:[EMAIL PROTECTED] > > Hmm, from all your comments it seems you have pointed > out that the best solution would be for types to have > no knowledge whatsoever of refids. True. > Of course this is > not possible under the gaze of the BC monster. We > could always start the mythological Ant 2 after 1.7 to > apply the learning of the past several years. I'll > keep thinking about this, though. But assuming that the framework starts unconditionally handling datatype refids, then older code keeps on working just fine. The old setRefid() methods never get called (by the framework), and the manual checks succeed, while still catching erroneous programmatic use of setRefid(). New types just ignore refid altogether, and are greatly simplified. So on second thought, it sounds doable. The only possible break of BC I can foresee ATM would be for custom types, outside of Ant, which broke the unwritten rule that no attributes/elements are allowed once one uses refdid="someId", and I don't mind that ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: References
Hmm, from all your comments it seems you have pointed out that the best solution would be for types to have no knowledge whatsoever of refids. Of course this is not possible under the gaze of the BC monster. We could always start the mythological Ant 2 after 1.7 to apply the learning of the past several years. I'll keep thinking about this, though. -Matt --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > > From: Matt Benson [mailto:[EMAIL PROTECTED] > > > > Ever noticed that every Ant type that supports the > > id/refid pattern must include a load of custom > code? > > Why? Wouldn't it be possible in UE to check all > > DataType subclass elements for refid, validate no > > other attributes/elements/nested text, and > substitute > > the actual object? It doesn't appear that > DataType > > supports Locations so that wouldn't be an issue. > Who > > can point out any flaws in this approach? > > That's how it should have been in the first place > ;-) > > Would you change the data types' code to remove the > checks > and setRefid() methods? If not (for obvious BC > reasons), then > what should be the behavior between the old and new > way to > deal with refid? > > Also, the old "in code manual checks" of dealing > with refid > works even programmatically (like in
RE: References
> From: Matt Benson [mailto:[EMAIL PROTECTED] > > Ever noticed that every Ant type that supports the > id/refid pattern must include a load of custom code? > Why? Wouldn't it be possible in UE to check all > DataType subclass elements for refid, validate no > other attributes/elements/nested text, and substitute > the actual object? It doesn't appear that DataType > supports Locations so that wouldn't be an issue. Who > can point out any flaws in this approach? That's how it should have been in the first place ;-) Would you change the data types' code to remove the checks and setRefid() methods? If not (for obvious BC reasons), then what should be the behavior between the old and new way to deal with refid? Also, the old "in code manual checks" of dealing with refid works even programmatically (like in
