Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » Core: Null handling incoherent?
Core: Null handling incoherent? [message #32255] Wed, 04 May 2011 10:46 Go to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi all,

i'm wondering why
template <class T> bool IsNull(const T& x) { return x.IsNullInstance(); }


and not
template <class T> bool IsNull(const T& x) { return x.IsNull(); }


is there a reason for it? name clashes??
analogue to upp philosophy it should be latter case, ( Xmlize() { x.Xmlize() } etc.)

some classes define IsNullInstance(), some do IsNull(), it's kinda 'not clean'

(background: i'm tackling Null handling in terms of extension of Value with other types on user side (i.e. float), where the Null handlig is the major problem.)

EDIT:
it's also the point of what Null actually is.. is it only to be seen in context with Value handling? because all classes interacting with Value the classes need to know about Value, but Value.h defines some of the interface handling with the types as well. so it's mixed. (i.e. String.h has template definition of IsNull())..

maybe to think of null handling as kind a independant from Value and define it in Defs.h

template <class T> void SetNull(T& x) { x.SetNull(); }
template <class T> bool IsNull(const T& x) { return x.IsNullInstance(); }


so both, Value.h and all the others are aware of that concept..
this probably would also make sense to move Nuller concept to Defs.h

i'm currently making some changes, just trying to get trhough it properly..

[Updated on: Wed, 04 May 2011 11:22]

Report message to a moderator

Re: Core: Null handling incoherent? [message #32256 is a reply to message #32255] Wed, 04 May 2011 11:39 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
attached is a patch for discussion. the IsNullInstance naming issue is not adressed yet.

benefits:

* more clear coherent interface because IsNullInstance, SetNull are obligatory
* users can use RichValue<> as container for even own intrinsic types like float.., specifying themselves the null handling.
(but float f = Null; still wont work, since it has no converter, but SetNull<float>() can, which is a nice price to pay.
* specifying AsString<T> they can use the Value::ToString for it as well, i.e AsString<float> is already specified..

i'd have considered to have
template <class T> void SetNull(T& x) { x = Null; }

to make SetNull method optional, but Null is kind a wired with Value, which, at level of Defs.h isn't known yet..


  • Attachment: patch0.patch
    (Size: 5.77KB, Downloaded 176 times)
Re: Core: Null handling incoherent? [message #32262 is a reply to message #32256] Wed, 04 May 2011 13:38 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
tried it with SetNull() { x = Null; } which works fine as well, which eliminates the need of SetNull specialisation for the intrinsic Values.

here is the complete patch for it, it includes the moving of the Nuller stuff to Defs.h

  • Attachment: patch1.patch
    (Size: 6.37KB, Downloaded 228 times)

[Updated on: Wed, 04 May 2011 13:39]

Report message to a moderator

Re: Core: Null handling incoherent? [message #32283 is a reply to message #32255] Fri, 06 May 2011 09:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 04 May 2011 04:46

hi all,

i'm wondering why
template <class T> bool IsNull(const T& x) { return x.IsNullInstance(); }


and not
template <class T> bool IsNull(const T& x) { return x.IsNull(); }


is there a reason for it? name clashes??



You would not be able to use "IsNull" for other objects in any of T methods, without using 'Upp::' prefix -> very annoying...
Re: Core: Null handling incoherent? [message #32284 is a reply to message #32256] Fri, 06 May 2011 09:55 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 04 May 2011 05:39

attached is a patch for discussion. the IsNullInstance naming issue is not adressed yet.

benefits:

* more clear coherent interface because IsNullInstance, SetNull are obligatory



How have you defined IsNullInstance method for 'double'?

See, the obligatory interface is IsNull and Null asignment. IsNullInstance is just helper - it is easier to write it as method than as external function. SetNull was sort of forced by you.

Mirek
Re: Core: Null handling incoherent? [message #32289 is a reply to message #32284] Fri, 06 May 2011 10:43 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
that's why i tried a second version using the Null assignment (see the second patch) as the the global SetNull usage. the SetNull method as part of class interface besides IsNullInstance and Nuller ctor is not needed in that way.. it's kind a same approach as with global IsNull template.

the global template SetNull would be used by RichValue<> in GetNull(), which prevented the compile for the custom RichValue<float>.. since i couldnt specify additional operator float() in the Nuller (the idea of a template T() operator for Nuller is not practical for ambiguity reasons).

the IsNullInstance question was why there is no unique verision of IsNull API inside Value handled classes. sometimes they are IsNullInstance (which is dictated by IsNull<>) and sometimes it's IsNull, where a template specialisation is needed, like in Font..
is it legacy or should it be unified?

[Updated on: Fri, 06 May 2011 11:07]

Report message to a moderator

Re: Core: Null handling incoherent? [message #32292 is a reply to message #32289] Fri, 06 May 2011 13:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Fri, 06 May 2011 04:43


is it legacy or should it be unified?


In case of Font, unification would perhaps make sense, but it is IMO pretty low on priority.
Re: Core: Null handling incoherent? [message #32294 is a reply to message #32292] Fri, 06 May 2011 14:07 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
yeah, i agree..

but what about the first change...?
the global SetNull..this makes usage of RichValue<> with some intrinsic types possible (to a certain degree at least)..
are you willing to handle it like that?

[Updated on: Thu, 12 May 2011 21:10]

Report message to a moderator

Re: Core: Null handling incoherent? [message #32514 is a reply to message #32294] Mon, 23 May 2011 13:40 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
here comes a full patch with all i have encountered so far, it's not a lot more..Font, Draw, Painting. with the changes ide comiles without problems..
  • Attachment: patch4.patch
    (Size: 8.24KB, Downloaded 198 times)
Re: Core: Null handling incoherent? [message #33108 is a reply to message #32514] Thu, 07 July 2011 08:30 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi mirek..

what is your position towards this? this would make useability of custom unchangeable types usable in RichValue, just using the upp gloabal template means.. i think it's worth it..
Re: Core: Null handling incoherent? [message #33109 is a reply to message #33108] Thu, 07 July 2011 10:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
IMO, it solves too little for changes so big.

As said before, the standard interface is constructor from Null.

I understand the trouble with preexisting types, but IMO SetNull is only half-way solution.

Mirek
Re: Core: Null handling incoherent? [message #33110 is a reply to message #33109] Thu, 07 July 2011 10:35 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i dont encounter the changes too big, since the standard inline template assigns Null. it merely enables to override the means since for there are cases (like the complex, which we gladfully managed to solve in another way), where you neither can change the class (or dont want to) nor can you add a operator Foo() to Nuller. in those cases you specialize SetNull. to at least be able to use it with RichValue..

please reconsider it. it does not change any semantic.. =Null assignment is still the default..but it offers means to intercept..

what would be the full way solution? Smile

[Updated on: Thu, 07 July 2011 10:40]

Report message to a moderator

Re: Core: Null handling incoherent? [message #33788 is a reply to message #33110] Tue, 13 September 2011 18:08 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
hi mirek..
i'm depending on that a bit.. for my bazaar/LogPosCtrl...

take a look at bazaar/Gen/Vtypes.h/.cpp
there, i have Ctrl::LogPos RichValue'ized, which would not be possible without the SetNull template, since it has no from Nuller ctor.

if you are concerned about the several IsNull->IsNullInstance renames, i can provide a patch without it. but it only code cleanup. think of the last release date Very Happy we are far away..maybe a good chance to correct things.

for the float problem, i managed to circumvent the Value extension, but this is way more important, cause very general.

moving the things to Defs.h is just clean. since several other classes do depend on the stuff, that otherwise resides scattered in the code. again, the beginner user benefits from it encountering it where expected..
Re: Core: Null handling incoherent? [message #33796 is a reply to message #33788] Wed, 14 September 2011 09:46 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Do you think that adding an IsNull instantiation for unsigned would cause any troubles? Currently it fails to compile.
Re: Core: Null handling incoherent? [message #33798 is a reply to message #33796] Wed, 14 September 2011 12:46 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
what exactly did you compile? i cant reproduce any unsigned errors..when i try to compile the LogPosCtrlTest, it fails due to SetNull stuff not present...

imho, unsigned is not neccessary for Value..as mirek already lined out in an older thread, where i proposed to enrich value by all signed type.. Value does not care about the sizes of the representation, it cares only about the logic types, beeing bool, integer, and floating point values (represented by whatever highest available precision, bool, int64, double). int is merely from old days..

did you try the set null patch?

EDIT: heres the patch as svn patch again.. for a quick test
again, the changes are not deep, there are some .IsNull to .IsNullInstance renames for clean code base..the rest is block moving and some extensions

[Updated on: Wed, 14 September 2011 13:20]

Report message to a moderator

Re: Core: Null handling incoherent? [message #33812 is a reply to message #32255] Thu, 15 September 2011 12:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Wed, 04 May 2011 04:46

hi all,

i'm wondering why
template <class T> bool IsNull(const T& x) { return x.IsNullInstance(); }


and not
template <class T> bool IsNull(const T& x) { return x.IsNull(); }


is there a reason for it? name clashes??



Think about:

void Ctrl::TestSomething()
{
    String x = Something();
    if(IsNull(x)) ...
}


Mirek

[Updated on: Thu, 15 September 2011 12:57]

Report message to a moderator

Re: Core: Null handling incoherent? [message #33814 is a reply to message #33812] Thu, 15 September 2011 14:29 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
sorry, i cant get the fault Embarassed help, hint?
Re: Core: Null handling incoherent? [message #33815 is a reply to message #33814] Thu, 15 September 2011 15:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
When IsNull is method, compiler will presume you want to use it instead of global function. That is why method has to have different name.

Well, there might be some IsNull methods somewhere in concrete or special classes still. Not sure this needs fixing. IsNullInstance is contract to make IsNull work without specialized global function.

Mirek

[Updated on: Thu, 15 September 2011 15:38]

Report message to a moderator

Re: Core: Null handling incoherent? [message #33817 is a reply to message #33815] Thu, 15 September 2011 16:30 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
ok i was aware of this, but couldnt figure out what you where aiming at with the example..sorry..

this is totally clean approach. thats why the patch contains some fixes of some classes, (Uuid, Font), which use IsNull as member, which doesnt fit cleanly.

sorry for bothering you with this, but i really heavily rely on flexible Value extension for RichValue..and really hope you are alright with the propose or any alternative. since it does not change any semantic. =Null is still default assignment everywhere (the SetNull template is only used in RichValue..and uses =Null approach as inlined default). it offers possibility to override the =Null assignment and try the SetNull where needed, i.e. when using classes in RichValue, specified all from extern (seriliaze, xmlize, gethashvalue, as template specialisations)

i know it's not the full problem solution..is there any other idea?

Re: Core: Null handling incoherent? [message #33819 is a reply to message #33817] Fri, 16 September 2011 10:26 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Patch applied.

Mirek
Previous Topic: [SOLVED] String.GetCount with umlaut
Next Topic: read/write to /dev/rtp is happening .. but a small problem
Goto Forum:
  


Current Time: Fri Mar 29 11:24:34 CET 2024

Total time taken to generate the page: 0.01950 seconds