Menu
▾
▴
phptmapi-discuss
|
From: Johannes S. <top...@fr...> - 2010-02-02 22:33:57
|
Hi all, as PHPTMAPI is aligned to TMAPI I now wanted to update Construct::equals() and Construct::hashCode() according to updated semantics of equals() and hashCode() in final RC of TMAPI 2.0 [1]. Well, I am not really satisfied with this changing but missed the discussion on TMAPI mailing list. In final RC the semantics of equals() has changed from comparing the identity of TM CONSTRUCTS towards comparing the identity of (Java) OBJECTS. This is significantly different. Identity of TM constructs is "materialized" by TM system specific arbitrary identifiers [2]. IMO in federation of different topic maps from different TM systems processing of such construct identifiers must be omitted; focus is on processing the identity of subjects. To be honest: I'd like to preserve current semantics of PHPTMAPI equals(). Implementors will know how to identify PHP objects [3]. Thoughts? Best regards, Johannes [1] http://sourceforge.net/mailarchive/forum.php?thread_name=1521353800.20100113175400%40semagia.com&forum_name=tmapi-discuss [2] http://phptmapi.sourceforge.net/2.0/docs/core/Construct.html#getId [3] http://www.php.net/manual/en/language.oop5.object-comparison.php |
|
From: Johannes S. <top...@fr...> - 2010-02-03 20:37:39
|
Hi there, there is also the idea of Lars Heuer to just abolish equals() and hashCode(). Comparison of TM constructs as well as comparison of objects is then delegated to implementors. Johannes Johannes Schmidt schrieb: > Hi all, > as PHPTMAPI is aligned to TMAPI I now wanted to update > Construct::equals() and Construct::hashCode() according to updated > semantics of equals() and hashCode() in final RC of TMAPI 2.0 [1]. Well, > I am not really satisfied with this changing but missed the discussion > on TMAPI mailing list. In final RC the semantics of equals() has changed > from comparing the identity of TM CONSTRUCTS towards comparing the > identity of (Java) OBJECTS. This is significantly different. Identity of > TM constructs is "materialized" by TM system specific arbitrary > identifiers [2]. IMO in federation of different topic maps from > different TM systems processing of such construct identifiers must be > omitted; focus is on processing the identity of subjects. > To be honest: I'd like to preserve current semantics of PHPTMAPI > equals(). Implementors will know how to identify PHP objects [3]. Thoughts? > > Best regards, > Johannes > > > [1] > http://sourceforge.net/mailarchive/forum.php?thread_name=1521353800.20100113175400%40semagia.com&forum_name=tmapi-discuss > [2] http://phptmapi.sourceforge.net/2.0/docs/core/Construct.html#getId > [3] http://www.php.net/manual/en/language.oop5.object-comparison.php > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Phptmapi-discuss mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phptmapi-discuss > > > |
|
From: Lars H. <he...@se...> - 2010-02-04 15:03:52
|
Hi Johannes, > there is also the idea of Lars Heuer to just abolish equals() and > hashCode(). Comparison of TM constructs as well as comparison of objects > is then delegated to implementors. Well, my proposal was to remove hashCode() and equals() since they wouldn't be used by PHP anyway (i.e. if something is added as key to an array), but the behaviour of the implementations must be predictable of course (c.f. unit tests). Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Johannes S. <top...@fr...> - 2010-02-05 14:41:54
|
Hi Lars,
Lars Heuer schrieb:
> Well, my proposal was to remove hashCode() and equals() since they
> wouldn't be used by PHP anyway (i.e. if something is added as key to
> an array), but the behaviour of the implementations must be
> predictable of course (c.f. unit tests).
>
not sure what you mean by "predictable". Do you have an example?
Using objects as keys like
$topics[$topic1] = 'foo';
$topics[$topic2] = 'bar';
and then doing
count($topics);// 1 or 2
is in the scope of PHP (comparison of objects). In contrast, in a TM
scope there should be answered the question if $topic1 represents the
same TM construct (Topic) as $topic2. (Or: represent the same subject on
Topic level which then may trigger merging.) Answer could be TRUE
although spl_object_hash($topic1) != spl_object_hash($topic2) holds.
Implementors could introduce equalsConstruct(Construct $construct):
if (!$topic1->equalsConstruct($topic2) {
$topics[$topic2] = 'bar';
}
Best regards,
Johannes
> Best regards,
> Lars
>
|
|
From: Johannes S. <top...@fr...> - 2010-02-06 16:57:46
|
Hi Lars, hi all, I think that preserving the status quo is ok. Obviously, the method names cause specific expectations for, at least, Java people as equals() and hashCode() are Java natives. We could change equals() to equalsConstruct() and hashCode() to constructHashCode() to be more precise/explicit. Best regards, Johannes Lars Heuer schrieb: > Forgot to include the list.... again... > > > This is a forwarded message > > Date: Friday, February 5, 2010 4:11:31 PM > Subject: [Phptmapi-discuss] Construct::equals() and Construct::hashCode() > > ===8<==============Original message text=============== > > Hi Johannes, > > [...] > >>> Well, my proposal was to remove hashCode() and equals() since they >>> wouldn't be used by PHP anyway (i.e. if something is added as key to >>> an array), but the behaviour of the implementations must be >>> predictable of course (c.f. unit tests). >>> > > >> not sure what you mean by "predictable". Do you have an example? >> > > predictable: All implementations must behave the same. You wrote in > another e-mail: > > """ > [...] comparison of objects is then delegated to implementors > """ > > I just wanted to ensure this does not open the door for > incompatibilities between implementations. > > Best regards, > Lars > |
|
From: Lars H. <he...@se...> - 2010-02-06 17:08:20
|
Hallo Johannes, [...] > I think that preserving the status quo is ok. Obviously, the method > names cause specific expectations for, at least, Java people as equals() > and hashCode() are Java natives. We could change > equals() to equalsConstruct() and > hashCode() to constructHashCode() I still think that these methods are useless in the PHP world. If I'd have more deep PHP OOP skills, I'd give a more precise advice, but I am not familiar with PHP OOP (anymore). If you want to keep them, why don't you keep the names as well? Best regards, Lars -- Semagia <http://www.semagia.com> |
|
From: Johannes S. <top...@fr...> - 2010-02-07 14:26:58
|
Hi Lars, Lars Heuer schrieb: > > I still think that these methods are useless in the PHP world. I thought that they are useful for the TM world/scope. QTM uses equals() 27 times to check whether two TM constructs are equal ($this->getId() === $other->getId()). Yes, I could "introduce" them in QTM, however I guess that other implementors would also introduce a method like equals(). So why not providing it in PHPTMAPI? (Well, it's an assumption.) > If I'd > have more deep PHP OOP skills, I'd give a more precise advice, but I > am not familiar with PHP OOP (anymore). > > If you want to keep them, why don't you keep the names as well? > It was just an idea to avoid Java people expecting same behavior as Java equals() and hashCode() :) Well, finally, I'm fine preserving the status quo (semantics and naming). This would allow us to release RC1 as final version 2.0. Best regards, Johannes > Best regards, > Lars > |
|
From: Lars H. <he...@se...> - 2010-02-05 17:46:28
|
Forgot to include the list.... again...
This is a forwarded message
Date: Friday, February 5, 2010 4:11:31 PM
Subject: [Phptmapi-discuss] Construct::equals() and Construct::hashCode()
===8<==============Original message text===============
Hi Johannes,
[...]
>> Well, my proposal was to remove hashCode() and equals() since they
>> wouldn't be used by PHP anyway (i.e. if something is added as key to
>> an array), but the behaviour of the implementations must be
>> predictable of course (c.f. unit tests).
> not sure what you mean by "predictable". Do you have an example?
predictable: All implementations must behave the same. You wrote in
another e-mail:
"""
[...] comparison of objects is then delegated to implementors
"""
I just wanted to ensure this does not open the door for
incompatibilities between implementations.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
===8<===========End of original message text===========
|
Thanks for helping keep SourceForge clean.
X