css.container.XMap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

css.container.XMap

frank.schoenheit
Hi,

being in need of some generic map interface in UNO, I suggest
introducing the attached css.container.XMap interface in module udkapi.

The interface is roughly designed after the Map class from the Java
Collections Framework.

Any comments on the suggested design are welcome ...

Since the interface is a little bit bigger than the canonical
"has/insert/remove" triple, I also thought about introducing a
css.container.Map default implementation, which as constructor arguments
takes a key and a value type, and defaults certain behavior. This would
include the definition of key equality, the fact that no NULL keys are
allowed (while NULL values are), and perhaps more. Would that make sense?

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

/*************************************************************************
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* Copyright 2008 by Sun Microsystems, Inc.
*
* OpenOffice.org - a multi-platform office productivity suite
*
* $RCSfile: code,v $
*
* $Revision: 1.3 $
*
* This file is part of OpenOffice.org.
*
* OpenOffice.org is free software: you can redistribute it and/or modify
* it under the terms of the GNU Lesser General Public License version 3
* only, as published by the Free Software Foundation.
*
* OpenOffice.org is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
* GNU Lesser General Public License version 3 for more details
* (a copy is included in the LICENSE file that accompanied this code).
*
* You should have received a copy of the GNU Lesser General Public License
* version 3 along with OpenOffice.org.  If not, see
* <http://www.openoffice.org/license.html>
* for a copy of the LGPLv3 License.
************************************************************************/

#ifndef __com_sun_star_container_XMap_idl__
#define __com_sun_star_container_XMap_idl__

#include <com/sun/star/container/XEnumerationAccess.idl>
#include <com/sun/star/beans/IllegalTypeException.idl>
#include <com/sun/star/lang/NullPointerException.idl>
#include <com/sun/star/lang/NoSupportException.idl>
#include <com/sun/star/lang/IllegalArgumentException.idl>
#include <com/sun/star/container/NoSuchElementException.idl>
#include <com/sun/star/container/XSet.idl>

//=============================================================================

module com { module sun { module star { module container {

//=============================================================================

/** describes a map between keys and values.

    <p>Keys in the map are unique, and each key maps to exactly one value.</p>
*/
interface XMap
{
    /** provides access to an enumeration for all the elements in the map

        <p>The elements returned by the enumeration are instances of <type scope="com::sun::star::beans">Pair</type>,
        holding the key-value-pairs which are currently part of the map.</p>

        <p>The enumeration behavior is undefined when the map is modified while the enumeration is running.</p>
    */
    interface XEnumerationAccess;

    /** denotes the type of the keys in the map.

        <p>Implementations are free to accept any supertype of <code>KeyType</code> as keys.</p>
    */
    [attribute, readonly]   type    KeyType;

    /** denotes the type of the values in the map.

        <p>Implementations are free to accept any supertype of the <code>ValueType</code> as values.</p>
    */
    [attribute, readonly]   type    ValueType;

    /** denotes the number of elements in the map.
    */
    [attribute, readonly]   long    Size;

    /** indicates whether the map is currently empty.
    */
    [attribute, readonly]   boolean IsEmpty;

    /** provides access to the set of the keys of all mappings in the map

        <p>The map and the key set are linked, in that changes to any of the two are reflected in the other,
        too. However, inserting new elements into the key set is not supported.</p>

        <p>If you modify the key set while an enumeration of key set elements or map elements is running,
        the behavior of the enumeration is undefined.</p>
    */
    [attribute, readonly]   XSet    KeySet;

    /** provides access to an enumeration of the values of all mappings in the map

        <p>The map and the value collection are linked, in that changes in the map are reflected in the value
        collection, too.</p>

        <p>If you modify the map while an enumeration of values is running,
        the behavior of the enumeration is undefined.</p>
    */
    [attribute, readonly]   XEnumerationAccess
                                    Values;

    /** clears the map, removing all key-value pairs from it.

        @throws ::com::sun::star::beans::NoSupportException
            if the map is not mutable.
    */
        void clear()
        raises( ::com::sun::star::lang::NoSupportException );

    /** determines whether a mapping for he given key exists in the map

        @param _key
            is the key whose presence in the map is to be tested.
        @return
            <TRUE/> if and only if the map contains a mapping for the given key.

        @throws ::com::sun::star::beans::IllegalTypeException
            if the given key is not of a type which is accepted by the map
        @throws ::com::sun::star::beans::NullPointerException
            if the given key is <NULL/>, but the map does not accept <NULL/> keys.
    */
    boolean containsKey( [in] any _key )
        raises( ::com::sun::star::beans::IllegalTypeException,
                ::com::sun::star::lang::NullPointerException );

    /** determines whether the map contains a mapping to a given value.

        @param _value
            is the value whose presence in the map is to be tested.
        @return
            <TRUE/> if and only one or more keys map to the given value.

        @throws ::com::sun::star::beans::IllegalTypeException
            if the given value is not of a type which is accepted by the map
        @throws ::com::sun::star::beans::NullPointerException
            if the given value is <NULL/>, but the map does not accept <NULL/> values.
    */
    boolean containsValue( [in] any _value )
        raises( ::com::sun::star::beans::IllegalTypeException,
                ::com::sun::star::lang::NullPointerException );

    /** gets the value to which a given key maps.

        @param _key
            they key whose associated value is to be returned.
        @return
            the value which is associated with the given key.

        @throws ::com::sun::star::beans::IllegalTypeException
            if the given key is not of a type which is accepted by the map
        @throws ::com::sun::star::beans::NullPointerException
            if the given key is <NULL/>, but the map does not accept <NULL/> keys.
        @throws ::com::sun::star::container::NoSuchElementException
            if there is no value associated with the given key
    */
    any     get( [in] any _key )
        raises( ::com::sun::star::beans::IllegalTypeException,
                ::com::sun::star::lang::NullPointerException,
                ::com::sun::star::container::NoSuchElementException );

    /** associates a given key with a given value

        <p>If the map already contains a mapping for the given key, then the old value is replaced by the
        given new value.</p>

        @param _key
            is the key which the given value should be associated with
        @param _value
            is the value which should be associated with the given key
        @return
            the value which was previously associated with the given key, or <NULL/>
            if there was no such previous association.

        @throws ::com::sun::star::beans::IllegalTypeException
            if the given key is not of a type which is accepted by the map
        @throws ::com::sun::star::beans::NullPointerException
            if the given key is <NULL/>, but the map does not accept <NULL/> keys, or
            if the given value is <NULL/>, but the map does not accept <NULL/> values
        @throws ::com::sun::star::beans::NoSupportException
            if the map does not support putting new mappings into it
        @throws ::com::sun::star::lang::IllegalArgumentException
            if the given mapping cannot be stored in the map, since it does not fulfill
            additional requirements.
    */
    any     put( [in] any _key, [in] any _value )
        raises( ::com::sun::star::lang::NoSupportException,
                ::com::sun::star::beans::IllegalTypeException,
                ::com::sun::star::lang::NullPointerException,
                ::com::sun::star::lang::IllegalArgumentException );

    /** removes a key-value mapping, given by key, from the map.

        @param _key
            is the key whose mapping should be removed from the map
        @return
            the value which was associated with the given key before the removal

        @throws ::com::sun::star::beans::IllegalTypeException
            if the given key is not of a type which is accepted by the map
        @throws ::com::sun::star::beans::NullPointerException
            if the given key is <NULL/>, but the map does not accept <NULL/> keys.
        @throws ::com::sun::star::beans::NoSupportException
            if the map does not support putting new mappings into it
        @throws ::com::sun::star::container::NoSuchElementException
            if there is no value associated with the given key
    */
    any     remove( [in] any _key )
        raises( ::com::sun::star::lang::NoSupportException,
                ::com::sun::star::beans::IllegalTypeException,
                ::com::sun::star::lang::NullPointerException,
                ::com::sun::star::container::NoSuchElementException );
};

//=============================================================================

}; }; }; };

//=============================================================================

#endif


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
> /*************************************************************************
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * Copyright 2008 by Sun Microsystems, Inc.
> *
> * OpenOffice.org - a multi-platform office productivity suite
> *
> * $RCSfile: code,v $
> *
> * $Revision: 1.3 $

Uhm, I should probably adjust my "new source file" template to the age
of subversion, and remove those vairables :)

Ciao
Frank


--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/06/09 22:00, Frank Schönheit - Sun Microsystems Germany wrote:

>> /*************************************************************************
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * Copyright 2008 by Sun Microsystems, Inc.
>> *
>> * OpenOffice.org - a multi-platform office productivity suite
>> *
>> * $RCSfile: code,v $
>> *
>> * $Revision: 1.3 $
>
> Uhm, I should probably adjust my "new source file" template to the age
> of subversion, and remove those vairables :)

<http://www.openoffice.org/dev_docs/source/templates/code>, supposedly
maintained by st

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

Andre Fischer - Sun Microsystems Germany
In reply to this post by frank.schoenheit
Hello Frank,


Frank Schönheit - Sun Microsystems Germany wrote:
> Hi,
>
> being in need of some generic map interface in UNO, I suggest
> introducing the attached css.container.XMap interface in module udkapi.
>
> The interface is roughly designed after the Map class from the Java
> Collections Framework.
>
> Any comments on the suggested design are welcome ...

I wonder if Size, IsEmpty, and KeySet really should be attributes.
They are marked as readonly so I half expect them to be also immutable.
  Especially so as they are listed below KeyType and ValueType which
probably are immutable.

Is this how attributes can or should be used?


>
> Since the interface is a little bit bigger than the canonical
> "has/insert/remove" triple, I also thought about introducing a
> css.container.Map default implementation, which as constructor arguments
> takes a key and a value type, and defaults certain behavior. This would
> include the definition of key equality, the fact that no NULL keys are
> allowed (while NULL values are), and perhaps more. Would that make sense?
>
> Ciao
> Frank
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

Best regards,
Andre

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
Hi Andre,

> I wonder if Size, IsEmpty, and KeySet really should be attributes.
> They are marked as readonly so I half expect them to be also immutable.
>   Especially so as they are listed below KeyType and ValueType which
> probably are immutable.
>
> Is this how attributes can or should be used?

Interesting question. I cannot really give a convincing argument why I
chose attributes for this - it's just that I tend to use attribs for
read-only facets.

Opinions? Anybody who knows rules for when to use attributes vs. methods?

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/09/09 11:45, Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Andre,
>
>> I wonder if Size, IsEmpty, and KeySet really should be attributes.
>> They are marked as readonly so I half expect them to be also immutable.
>>   Especially so as they are listed below KeyType and ValueType which
>> probably are immutable.
>>
>> Is this how attributes can or should be used?
>
> Interesting question. I cannot really give a convincing argument why I
> chose attributes for this - it's just that I tend to use attribs for
> read-only facets.
>
> Opinions? Anybody who knows rules for when to use attributes vs. methods?

No rules.  However, using read-only attributes instead of methods to
retrieve volatile data, while technically OK, looked odd to me, too.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
Hi Stephan,

>> Opinions? Anybody who knows rules for when to use attributes vs. methods?
>
> No rules.  However, using read-only attributes instead of methods to
> retrieve volatile data, while technically OK, looked odd to me, too.

I'll take that as rule then ;), and will change IsEmpty and Size to
isEmpty and getSize.

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
In reply to this post by frank.schoenheit
> being in need of some generic map interface in UNO, I suggest
> introducing the attached css.container.XMap interface in module udkapi.
> ...
> Since the interface is a little bit bigger than the canonical
> "has/insert/remove" triple, I also thought about introducing a
> css.container.Map default implementation,

FYI: the latest versions:
http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/XMap.idl
http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/Map.idl

You still have the chance to veto this (if you have a good reasoning :)
before the CWS will be finalized ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/19/09 22:58, Frank Schönheit - Sun Microsystems Germany wrote:

>> being in need of some generic map interface in UNO, I suggest
>> introducing the attached css.container.XMap interface in module udkapi.
>> ...
>> Since the interface is a little bit bigger than the canonical
>> "has/insert/remove" triple, I also thought about introducing a
>> css.container.Map default implementation,
>
> FYI: the latest versions:
> http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/XMap.idl
> http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/Map.idl
>
> You still have the chance to veto this (if you have a good reasoning :)
> before the CWS will be finalized ...

Seeing that you want to put that into udkapi, I'll have a closer look:  ;)

- Parameter names starting with an underscore are not valid.

- KeySet:  How is "inserting new elements into the key set is not
supported" handled (e.g., is it specified what exception gets raised)?

- KeySet.has, KeySet.remove, containsKey, containsValue, get, put,
remove:  You need to clarify how to compare the involved values for
equality.

- Values:  "The map and the value collection are linked, in that changes
in the map are reflected in the value collection, too." and "If you
modify the map while an enumeration of values is running, the behavior
of the enumeration is undefined." look like they are at odds with each
other.  What exactly is meant with "while an enumeration of values is
running"?

- getSize:  Is it needed?  (At least theoretically, the return type
poses a problem that could be prevented simply by leaving that method out.)

- containsKey, containsValue, get, put, remove:  Why the
NullPointerException?  Why would an implementation choose not to support
null references to interfaces as keys and/or values?  How would
KeySet.has and KeySet.remove handle this?

- get:  I would let it return Optional<any> and not raise
NoSuchElementException, so that it can be used more naturally in
multi-threaded scenarios.

- put:  Better let it return Optional<any>.  What exactly is meant with
"@return [...] <NULL/> if there was no such previous association"?

- remove:  An alternative would be to let it return Optional<any> and
not raise NoSuchElementException (again, this might be more appropriate
in certain multi-threaded scenarios).

- create, createImmutable:  You need to clarify what "unsupported types"
are.

- create:  You need to clarify whether and when put on the resulting
XMap will raise IllegalArgumentException.

- createImmutable:  How are invalid elements in _values handled?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
Hi Stephan,

> Seeing that you want to put that into udkapi, I'll have a closer look:  ;)

hehe :)

> - Parameter names starting with an underscore are not valid.

Damn, and I thought you sanctified those by not objecting in the first
round ...
(I don't like the generated headers in C++ not having underscores or
parameters, so I usually try to smuggle underscores into the IDL ...)

Fixed.

> - KeySet:  How is "inserting new elements into the key set is not
> supported" handled (e.g., is it specified what exception gets raised)?

XSet::insert allows for ElementExists and InvalidArgument only, so I
chose the latter.

Added to documentation.

> - KeySet.has, KeySet.remove, containsKey, containsValue, get, put,
> remove:  You need to clarify how to compare the involved values for
> equality.

Why? Isn't this an implementation detail? In other words, shouldn't the
service implementing XMap specify this?
Hmm, okay, in this case your next request will be adding this to
css.container.Map :). Sadly, I don't have the slightest idea how I
should write in prose what (I think)
"css::uno::Any::operator==(css::uno::Any)" does ...

> - Values:  "The map and the value collection are linked, in that changes
> in the map are reflected in the value collection, too." and "If you
> modify the map while an enumeration of values is running, the behavior
> of the enumeration is undefined." look like they are at odds with each
> other.  What exactly is meant with "while an enumeration of values is
> running"?

Hmm ... That's an edge case, probably, depending on exactly the sentence
you pointed out.
Perhaps I should just state that operating on an XEnumeration object
which has been created (by XEnumerationAccess::createEnumeration)
*before* a change to the map happened yields undefined behavior. Would
that be better?

I also thought about simply requesting to invalidate (as in: will throw
a DisposedException when used) all enumerators (for keys, values, and
mapping pairs) once the map is modified. Would probably be the most
stringent requirement, but quite reasonable. What do you think?

> - getSize:  Is it needed?  (At least theoretically, the return type
> poses a problem that could be prevented simply by leaving that method out.)

What's the problem with the return type?

For one, I added this method for consistency with java.util.Map, which
strongly inspired the interface.

Then, I am undecided. In scenarios with a clear control over a given map
(i.e. where you have confidence no other instances tampers with it), it
might be interesting to know how many elements it contains, without
enumerating them all.

So, all in all, I'm in slight favor of keeping it.

> - containsKey, containsValue, get, put, remove:  Why the
> NullPointerException?  Why would an implementation choose not to support
> null references to interfaces as keys and/or values?  How would
> KeySet.has and KeySet.remove handle this?

Not supporting NULL for either keys or values could probably be
justified (for a concrete implementation) by the additional
implementation effort/complexity it would cost. Imagine an
implementation which internally uses the strict weak ordering on allowed
keys (or even allowed values, if it chooses a certain less-than-O(n)
implementation of containsValue) - allowing for NULL keys (values) would
make the implementation more difficult. So the implementor might decide
that that's just not worth it for the intended use cases.

KeySet::has can only return false, since it does not allow for an
appropriate exception. Which, in some sense, is consistent with existing
XSet implementations - invalid keys cannot but treated as "not contained".

KeySet::remove does not have a problem, since that's unsupported, anyway
- so any other suitable exception can be thrown before actually checking
the passed key.


Of course, even if this perhaps convinced you :), it might still be
debatable whether "Null*Pointer*Exception" really is the right thing
here. Again, this was inspired by java.util.Map.

> - get:  I would let it return Optional<any> and not raise
> NoSuchElementException, so that it can be used more naturally in
> multi-threaded scenarios.

Hmm. I don't like Optionals. In single-threaded scenarios, they
unnecessarily complicate the usage.

> - put:  Better let it return Optional<any>.  What exactly is meant with
> "@return [...] <NULL/> if there was no such previous association"?

In the complete wording, it is

  @return
    the value which was previously associated with the given key, or
    <NULL/>, if there was no such previous association.

so, I had hope this is read as "no mapping existed for the given Key".

> - remove:  An alternative would be to let it return Optional<any> and
> not raise NoSuchElementException (again, this might be more appropriate
> in certain multi-threaded scenarios).

Okay, we have "I would let it return Optional...", "Better let it return
Optional..." and "An alternative would be to let it return Optional...".
Can you decide for one of those? :)

> - create, createImmutable:  You need to clarify what "unsupported types"
> are.

Done.

> - create:  You need to clarify whether and when put on the resulting
> XMap will raise IllegalArgumentException.

Done. Please review, I also added a new paragraph about accepting value
types.

> - createImmutable:  How are invalid elements in _values handled?

Now throws an IllegalArgumentException. I applied both rule sets (for
keys and values) to both create=>XMap::put and createImmutable.


Thanks & Ciao
Frank

--
Frank Schönheit                         StarOffice/OpenOffice.org Base
[hidden email]                    +49 40 23 646 663 / +66663
Sun Microsystems Germany                         Hamburg, Nagelsweg 55
----------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/20/09 12:38, Frank Schönheit wrote:

>> - KeySet.has, KeySet.remove, containsKey, containsValue, get, put,
>> remove:  You need to clarify how to compare the involved values for
>> equality.
>
> Why? Isn't this an implementation detail? In other words, shouldn't the
> service implementing XMap specify this?
> Hmm, okay, in this case your next request will be adding this to
> css.container.Map :). Sadly, I don't have the slightest idea how I
> should write in prose what (I think)
> "css::uno::Any::operator==(css::uno::Any)" does ...

I would use structural induction over the format of UNO types (see
<http://udk.openoffice.org/common/man/typesystem.html>).

>> - Values:  "The map and the value collection are linked, in that changes
>> in the map are reflected in the value collection, too." and "If you
>> modify the map while an enumeration of values is running, the behavior
>> of the enumeration is undefined." look like they are at odds with each
>> other.  What exactly is meant with "while an enumeration of values is
>> running"?
>
> Hmm ... That's an edge case, probably, depending on exactly the sentence
> you pointed out.
> Perhaps I should just state that operating on an XEnumeration object
> which has been created (by XEnumerationAccess::createEnumeration)
> *before* a change to the map happened yields undefined behavior. Would
> that be better?

Looks better.  However, you should then drop "The map and the value
collection are linked, in that changes in the map are reflected in the
value collection, too."

Also, the descriptions of the XEnumerationAccess base interface and
KeySet should be changed to the clearer wording, too.

> I also thought about simply requesting to invalidate (as in: will throw
> a DisposedException when used) all enumerators (for keys, values, and
> mapping pairs) once the map is modified. Would probably be the most
> stringent requirement, but quite reasonable. What do you think?

Not sure whether this is easily implementable, so I would simply stick
to undefined behavior.

>> - getSize:  Is it needed?  (At least theoretically, the return type
>> poses a problem that could be prevented simply by leaving that method out.)
>
> What's the problem with the return type?

What about a map that holds 2^31 elements?

>> - containsKey, containsValue, get, put, remove:  Why the
>> NullPointerException?  Why would an implementation choose not to support
>> null references to interfaces as keys and/or values?  How would
>> KeySet.has and KeySet.remove handle this?
>
> Not supporting NULL for either keys or values could probably be
> justified (for a concrete implementation) by the additional
> implementation effort/complexity it would cost. Imagine an
> implementation which internally uses the strict weak ordering on allowed
> keys (or even allowed values, if it chooses a certain less-than-O(n)
> implementation of containsValue) - allowing for NULL keys (values) would
> make the implementation more difficult. So the implementor might decide
> that that's just not worth it for the intended use cases.

I fail to see how null interface references complicate things here.

> KeySet::has can only return false, since it does not allow for an
> appropriate exception. Which, in some sense, is consistent with existing
> XSet implementations - invalid keys cannot but treated as "not contained".

You meant "invalid keys cannot be treated as 'contained'"?

> KeySet::remove does not have a problem, since that's unsupported, anyway
> - so any other suitable exception can be thrown before actually checking
> the passed key.

I thought it was KeySet.insert that is (implicitly) unsupported, not
KeySet.remove?

> Of course, even if this perhaps convinced you :), it might still be
> debatable whether "Null*Pointer*Exception" really is the right thing
> here. Again, this was inspired by java.util.Map.

I doubt that the Java inspiration is useful here.  Null in Java is a
rather different concept from null in UNO (e.g., only interface
references can be null in UNO, while references to all non-primitive
types can be null in Java).

>> - get:  I would let it return Optional<any> and not raise
>> NoSuchElementException, so that it can be used more naturally in
>> multi-threaded scenarios.
>
> Hmm. I don't like Optionals. In single-threaded scenarios, they
> unnecessarily complicate the usage.

Hm, I don't like exceptions, they unnceessarily complicate the usage... ;)

>> - put:  Better let it return Optional<any>.  What exactly is meant with
>> "@return [...] <NULL/> if there was no such previous association"?
>
> In the complete wording, it is
>
>   @return
>     the value which was previously associated with the given key, or
>     <NULL/>, if there was no such previous association.
>
> so, I had hope this is read as "no mapping existed for the given Key".

Sorry, what I meant is that "<NULL/>" is not a valid value for a UNO any.

>> - remove:  An alternative would be to let it return Optional<any> and
>> not raise NoSuchElementException (again, this might be more appropriate
>> in certain multi-threaded scenarios).
>
> Okay, we have "I would let it return Optional...", "Better let it return
> Optional..." and "An alternative would be to let it return Optional...".
> Can you decide for one of those? :)

No, the three cases are rather different.

>> - create, createImmutable:  You need to clarify what "unsupported types"
>> are.
>
> Done.

- Null keys not being allowed should be part of the interface type list
item, not a list item of its own.

- There is no UNO type named "int".

- For my tastes, these rules are too arbitrary for this "default
implementation."

>> - create:  You need to clarify whether and when put on the resulting
>> XMap will raise IllegalArgumentException.
>
> Done. Please review, I also added a new paragraph about accepting value
> types.

- There is no "the <NULL/> value" in UNO.  (Rather, for every interface
type T, there is a null value of that type.)

- "If the value type's class if" typo.

- There are no UNO types with TypeClass::UNION or TypeClass::UNKNOWN.
(com.sun.star.uno.TypeClass is in a poor state.  I would not mention it
at all in the definition of XMap/Map.)

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
Hi Stephan,

> Looks better.  However, you should then drop "The map and the value
> collection are linked, in that changes in the map are reflected in the
> value collection, too."
>
> Also, the descriptions of the XEnumerationAccess base interface and
> KeySet should be changed to the clearer wording, too.

Done and done.

>> I also thought about simply requesting to invalidate (as in: will throw
>> a DisposedException when used) all enumerators (for keys, values, and
>> mapping pairs) once the map is modified. Would probably be the most
>> stringent requirement, but quite reasonable. What do you think?
>
> Not sure whether this is easily implementable, so I would simply stick
> to undefined behavior.

It's pretty easy - my implementation already needs to care for a
modified map (I certainly did not want it to interpret "undefined" as
"allowed to crash"), so changing the current behavior to some "dispose"
is possible.

However, Andre Fischer (offline) raised concerns about multi-threading
usage of the whole interface. That is, since all three enumerators
(potentially) stop working as soon as the map is modified (e.g. by an
external instance), they become pretty useless as long as you cannot
lock the complete map while enumerating it - which you cannot.

Andre has a good point here. I think it could be solved by either
decoupling the enumerators from the map, so that createEnumeration
creates a copy of the to-be-enumerated elements. Alternatively, XMap
could provide some accessors retrieving a copy of all keys/values/mappings.

I am quite undecided which is better here. IMO it somewhat depends on
how often enumeration over all map elements is actually used - if pretty
often, copying should be made explicit, not implicit. If seldom, then
copying on enumerator creation might be bearable.

>>> - getSize:  Is it needed?  (At least theoretically, the return type
>>> poses a problem that could be prevented simply by leaving that method out.)
>> What's the problem with the return type?
>
> What about a map that holds 2^31 elements?

I was tempted to say "who needs that ...". Following this immediately
disqualifies the get-a-copy-approach above, at least with using
sequences, since those are limited to 2^31, too.

Admittedly, the other container types (e.g. XSet) do not provide a size,
either. (They also do not state whether enumerators work on a copy.)

Sigh. Will remove. For consistency reasons.

>>> - containsKey, containsValue, get, put, remove:  Why the
>>> NullPointerException?  Why would an implementation choose not to support
>>> null references to interfaces as keys and/or values?  How would
>>> KeySet.has and KeySet.remove handle this?
>> Not supporting NULL for either keys or values could probably be
>> justified (for a concrete implementation) by the additional
>> implementation effort/complexity it would cost. Imagine an
>> implementation which internally uses the strict weak ordering on allowed
>> keys (or even allowed values, if it chooses a certain less-than-O(n)
>> implementation of containsValue) - allowing for NULL keys (values) would
>> make the implementation more difficult. So the implementor might decide
>> that that's just not worth it for the intended use cases.
>
> I fail to see how null interface references complicate things here.

Okay, it seems I used the wrong terminology all the time. With NULL, I
actually meant anys being VOID (which don't have a canonical place in a
strict weak ordering). Changing this in the documentation reveals that
NullPointerException is indeed the wrong exception here, so I will
subsume this under IllegalArgumentException, too.

>> KeySet::has can only return false, since it does not allow for an
>> appropriate exception. Which, in some sense, is consistent with existing
>> XSet implementations - invalid keys cannot but treated as "not contained".
>
> You meant "invalid keys cannot be treated as 'contained'"?

I meant "Invalid keys can be treated as 'not contained' only" :)

>> KeySet::remove does not have a problem, since that's unsupported, anyway
>> - so any other suitable exception can be thrown before actually checking
>> the passed key.
>
> I thought it was KeySet.insert that is (implicitly) unsupported, not
> KeySet.remove?

My fault. I silently assumed "remove" is also unsupported, though I
documented only "insert" is.
Off to implement "remove" ...

>>> - remove:  An alternative would be to let it return Optional<any> and
>>> not raise NoSuchElementException (again, this might be more appropriate
>>> in certain multi-threaded scenarios).
>> Okay, we have "I would let it return Optional...", "Better let it return
>> Optional..." and "An alternative would be to let it return Optional...".
>> Can you decide for one of those? :)
>
> No, the three cases are rather different.

But we certainly do not want only one or two of the three methods return
an Optional, do we?

I do not dare to introduce the Optional here, since in particular for
(known-to-be) immutable maps (which I think will happen quite often),
it's indeed overhead - in the current shape, a client could safely
"ignore" (well: handle ungracefully) NoSuchElementExceptions after
has/get, since they will not happen.

What about adding an XConcurrentMap, having
- Optional< any > getIfPresent( [in] any Key );
- Optional< any > putIfAbsent( [in] any Key, [in] any Value );
- Optional< any > replaceIfPresent( [in] any Key, [in] any Value );
- boolean         replaceIfMapped( [in] any Key, [in] any OldValue,
                                   [in] any NewValue );

>>> - create, createImmutable:  You need to clarify what "unsupported types"
>>> are.
>> Done.
>
> - Null keys not being allowed should be part of the interface type list
> item, not a list item of its own.

See above - I always meant VOID when I wrote NULL.

> - There is no UNO type named "int".

Fixed.

> - For my tastes, these rules are too arbitrary for this "default
> implementation."

Can you elaborate?

The only "unreasonable restriction" I see at the moment is that certain
key types are rejected - notably those which do not have a canonical
strict weak ordering. I admit this is implementation-driven ... Would
you require this to be changed?

The only "unreasonable relaxation" I see at the moment is the widening
conversion for integer types. Again, this is also implementation-driven
(by your disliked "operator>>=( Any, <inttype> )"), but could easily be
changed. I'd be comfortable with removing this relaxation, if you
request it.

Anything more "too arbitrary"?

> - There is no "the <NULL/> value" in UNO.  (Rather, for every interface
> type T, there is a null value of that type.)

But <VOID/> is a dedicated value, right?

> - "If the value type's class if" typo.

Fixed.

> - There are no UNO types with TypeClass::UNION or TypeClass::UNKNOWN.
> (com.sun.star.uno.TypeClass is in a poor state.  I would not mention it
> at all in the definition of XMap/Map.)

Removed. (not from the implementation. Who knows when you will
re-introduce those :)

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/20/09 15:34, Frank Schönheit - Sun Microsystems Germany wrote:
  >>> I also thought about simply requesting to invalidate (as in: will
throw

>>> a DisposedException when used) all enumerators (for keys, values, and
>>> mapping pairs) once the map is modified. Would probably be the most
>>> stringent requirement, but quite reasonable. What do you think?
>> Not sure whether this is easily implementable, so I would simply stick
>> to undefined behavior.
>
> It's pretty easy - my implementation already needs to care for a
> modified map (I certainly did not want it to interpret "undefined" as
> "allowed to crash"), so changing the current behavior to some "dispose"
> is possible.
>
> However, Andre Fischer (offline) raised concerns about multi-threading
> usage of the whole interface. That is, since all three enumerators
> (potentially) stop working as soon as the map is modified (e.g. by an
> external instance), they become pretty useless as long as you cannot
> lock the complete map while enumerating it - which you cannot.

You *can* do it (with a protocol on top of using a given XMap instance).

>>>> - containsKey, containsValue, get, put, remove:  Why the
>>>> NullPointerException?  Why would an implementation choose not to support
>>>> null references to interfaces as keys and/or values?  How would
>>>> KeySet.has and KeySet.remove handle this?
>>> Not supporting NULL for either keys or values could probably be
>>> justified (for a concrete implementation) by the additional
>>> implementation effort/complexity it would cost. Imagine an
>>> implementation which internally uses the strict weak ordering on allowed
>>> keys (or even allowed values, if it chooses a certain less-than-O(n)
>>> implementation of containsValue) - allowing for NULL keys (values) would
>>> make the implementation more difficult. So the implementor might decide
>>> that that's just not worth it for the intended use cases.
>> I fail to see how null interface references complicate things here.
>
> Okay, it seems I used the wrong terminology all the time. With NULL, I
> actually meant anys being VOID (which don't have a canonical place in a
> strict weak ordering). Changing this in the documentation reveals that
> NullPointerException is indeed the wrong exception here, so I will
> subsume this under IllegalArgumentException, too.

I still do not understand.  There are two cases where void any values as
keys would be valid---if KeyType is "void" and if KeyType is "any".  In
the first case, a strict weak ordering is trivial.  In the second case,
allowing void any values (in addition to all the other any values) does
not further complicate a strict weak ordering.

>>>> - remove:  An alternative would be to let it return Optional<any> and
>>>> not raise NoSuchElementException (again, this might be more appropriate
>>>> in certain multi-threaded scenarios).
>>> Okay, we have "I would let it return Optional...", "Better let it return
>>> Optional..." and "An alternative would be to let it return Optional...".
>>> Can you decide for one of those? :)
>> No, the three cases are rather different.
>
> But we certainly do not want only one or two of the three methods return
> an Optional, do we?
>
> I do not dare to introduce the Optional here, since in particular for
> (known-to-be) immutable maps (which I think will happen quite often),
> it's indeed overhead - in the current shape, a client could safely
> "ignore" (well: handle ungracefully) NoSuchElementExceptions after
> has/get, since they will not happen.
>
> What about adding an XConcurrentMap, having
> - Optional< any > getIfPresent( [in] any Key );
> - Optional< any > putIfAbsent( [in] any Key, [in] any Value );
> - Optional< any > replaceIfPresent( [in] any Key, [in] any Value );
> - boolean         replaceIfMapped( [in] any Key, [in] any OldValue,
>                                    [in] any NewValue );

I would not complicate the (already large) interface further.  Both
exceptions and optional "work," so if you want to stick with exceptions,
that should be no problem...

>>>> - create, createImmutable:  You need to clarify what "unsupported types"
>>>> are.
>>> Done.
>> - For my tastes, these rules are too arbitrary for this "default
>> implementation."
>
> Can you elaborate?
>
> The only "unreasonable restriction" I see at the moment is that certain
> key types are rejected - notably those which do not have a canonical
> strict weak ordering. I admit this is implementation-driven ... Would
> you require this to be changed?

Strict weak orderings for void, unsigned short, unsigned long, unsigned
hyper should be easy.  Also, strict weak orderings for sequence types
over types already covered should also be easy.  But I get your point:
Leave out "unreasonable" types that would lead to hassle in the
implementations (one might also want to leave out float and double,
given their peculiarities).

> The only "unreasonable relaxation" I see at the moment is the widening
> conversion for integer types. Again, this is also implementation-driven
> (by your disliked "operator>>=( Any, <inttype> )"), but could easily be
> changed. I'd be comfortable with removing this relaxation, if you
> request it.

I don't mind.  ;)

> Anything more "too arbitrary"?

No, got you now.

>> - There is no "the <NULL/> value" in UNO.  (Rather, for every interface
>> type T, there is a null value of that type.)
>
> But <VOID/> is a dedicated value, right?

Yes, the UNO type "void" is inhabited by exactly one value ("unit").

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
In reply to this post by stephan.bergmann
Hi Stephan,
>> Sadly, I don't have the slightest idea how I
>> should write in prose what (I think)
>> "css::uno::Any::operator==(css::uno::Any)" does ...
>
> I would use structural induction over the format of UNO types (see
> <http://udk.openoffice.org/common/man/typesystem.html>).

Interesting read ...

Luckily, I found the following there: "Two UNO values are equal if and
only if they have the same type t and both denote the same element of V_t."

I added (not yet committed) a reference to this manual page, and the
notion of equality defined there.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
In reply to this post by stephan.bergmann
Hi Stephan,

>> However, Andre Fischer (offline) raised concerns about multi-threading
>> usage of the whole interface. That is, since all three enumerators
>> (potentially) stop working as soon as the map is modified (e.g. by an
>> external instance), they become pretty useless as long as you cannot
>> lock the complete map while enumerating it - which you cannot.
>
> You *can* do it (with a protocol on top of using a given XMap instance).

Sure, but that notably complicates the usage, and is error-prone, since
it hard, up to impossible, to ensure everybody conforms to the protocol.

So, I really think Andre has a good point here, and I am tempted to
change enumerations to work on a copy.

> I still do not understand.  There are two cases where void any values as
> keys would be valid---if KeyType is "void" and if KeyType is "any".  In
> the first case, a strict weak ordering is trivial.  In the second case,
> allowing void any values (in addition to all the other any values) does
> not further complicate a strict weak ordering.

KeyType "void" is nothing I would support - a map which can hold at most
on entry seems somewhat useless to me.
KeyType "any" is also nothing I would support (in the default
implementation): I simply cannot imagine a strict weak ordering which
could be implemented with a reasonable effort, and I do not think an
unreasonable effort, or an implementation not using strict weak
orderings, and thus being O(n), is worth it.

In all other cases, it is at the implementations discretion whether for
a given KeyType, it is possible to put the VOID key into the map.
Strictly, you could say it should not be possible since actually, VOID
is not a value from KeyType's value set. It is "only" that the generic
API ("put( any, any)") allows for VOID keys, where a less generic API
("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
allow for it.
However, I would not restrict implementations too much, so I preferred
to leave it undecided in the interface definition whether VOID keys (or
values) are accepted.

>> What about adding an XConcurrentMap, having
>> - Optional< any > getIfPresent( [in] any Key );
>> - Optional< any > putIfAbsent( [in] any Key, [in] any Value );
>> - Optional< any > replaceIfPresent( [in] any Key, [in] any Value );
>> - boolean         replaceIfMapped( [in] any Key, [in] any OldValue,
>>                                    [in] any NewValue );
>
> I would not complicate the (already large) interface further.

Glad to hear that ;), though I admit I found the idea of XConcurrentMap
tempting ...

> Both
> exceptions and optional "work," so if you want to stick with exceptions,
> that should be no problem...

okay.

>> The only "unreasonable restriction" I see at the moment is that certain
>> key types are rejected - notably those which do not have a canonical
>> strict weak ordering. I admit this is implementation-driven ... Would
>> you require this to be changed?
>
> Strict weak orderings for void, unsigned short, unsigned long, unsigned
> hyper should be easy.

Sorry, forgot to mention (in both the mails and the doc) that unsigned
types are of course supported, too.

> Also, strict weak orderings for sequence types
> over types already covered should also be easy.

Ah, indeed, those could be added easily. Will perhaps do it.

> But I get your point:
> Leave out "unreasonable" types that would lead to hassle in the
> implementations (one might also want to leave out float and double,
> given their peculiarities).

I am not sure I should dare to ask ... with peculiarities of float and
double, you refer to what? The only thing I can imagine right now is
their ... imprecision, which shouldn't be a problem in this context. Do
they have more issues, perhaps when passed around crossing bridges?

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/20/09 23:04, Frank Schönheit - Sun Microsystems Germany wrote:

> In all other cases, it is at the implementations discretion whether for
> a given KeyType, it is possible to put the VOID key into the map.
> Strictly, you could say it should not be possible since actually, VOID
> is not a value from KeyType's value set. It is "only" that the generic
> API ("put( any, any)") allows for VOID keys, where a less generic API
> ("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
> allow for it.
> However, I would not restrict implementations too much, so I preferred
> to leave it undecided in the interface definition whether VOID keys (or
> values) are accepted.

Why special case VOID and not, say, CHAR?

>> But I get your point:
>> Leave out "unreasonable" types that would lead to hassle in the
>> implementations (one might also want to leave out float and double,
>> given their peculiarities).
>
> I am not sure I should dare to ask ... with peculiarities of float and
> double, you refer to what? The only thing I can imagine right now is
> their ... imprecision, which shouldn't be a problem in this context. Do
> they have more issues, perhaps when passed around crossing bridges?

Yes, equality over floating point numbers is complicated by precision
(e.g., in languages like C and C++, intermediates may arbitrarily be
kept in extended-precision registers, so that x+y==x+y need not be true)
and NaN (where NaN==NaN is false).

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
Hi Stephan,

>> In all other cases, it is at the implementations discretion whether for
>> a given KeyType, it is possible to put the VOID key into the map.
>> Strictly, you could say it should not be possible since actually, VOID
>> is not a value from KeyType's value set. It is "only" that the generic
>> API ("put( any, any)") allows for VOID keys, where a less generic API
>> ("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
>> allow for it.
>> However, I would not restrict implementations too much, so I preferred
>> to leave it undecided in the interface definition whether VOID keys (or
>> values) are accepted.
>
> Why special case VOID and not, say, CHAR?

Since in some sense (and you will probably have a link pointing to some
mathematical paper about the UNO type system which proves that this
sense is non-sense, actually), a VOID any where a Foo-typed any is
expected is more "natural" than a CHAR any at the same place.

> Yes, equality over floating point numbers is complicated by precision
> (e.g., in languages like C and C++, intermediates may arbitrarily be
> kept in extended-precision registers, so that x+y==x+y need not be true)
> and NaN (where NaN==NaN is false).

<sarcasm>So why do we have those types in UNO at all, if using them is
questionable?</sarcasm>

Within the "default implementation", the precision should not be a
problem, in my understanding - here, only values passed from outside are
compared, no actual calculations happen. So, it is left to the client to
care this.

Removing those types because some clients might not be able to do so
does not really sound like a good idea to me.


Side note: Andrey just convinced me to remove the widening conversions
in the key acceptance ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

Andre Fischer - Sun Microsystems Germany
In reply to this post by stephan.bergmann
Stephan Bergmann wrote:

> On 03/20/09 23:04, Frank Schönheit - Sun Microsystems Germany wrote:
>> In all other cases, it is at the implementations discretion whether for
>> a given KeyType, it is possible to put the VOID key into the map.
>> Strictly, you could say it should not be possible since actually, VOID
>> is not a value from KeyType's value set. It is "only" that the generic
>> API ("put( any, any)") allows for VOID keys, where a less generic API
>> ("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
>> allow for it.
>> However, I would not restrict implementations too much, so I preferred
>> to leave it undecided in the interface definition whether VOID keys (or
>> values) are accepted.
>
> Why special case VOID and not, say, CHAR?

I would prefer not to have special key at all.  The above reasoning
(put(any,any) allows VOID keys) is true for all types supported by ANY
and therefore is not really an argument for having a special key.

But if we really need a special case then I vote for VOID:

1. For type VOID there is only one value (whatever its name may be).
2. When the key type is CHAR then CHAR can not be the type of a special
case.  VOID has been ruled out as key type and therefore can be used as
special case for every key type.

>
>>> But I get your point: Leave out "unreasonable" types that would lead
>>> to hassle in the implementations (one might also want to leave out
>>> float and double, given their peculiarities).
>>
>> I am not sure I should dare to ask ... with peculiarities of float and
>> double, you refer to what? The only thing I can imagine right now is
>> their ... imprecision, which shouldn't be a problem in this context. Do
>> they have more issues, perhaps when passed around crossing bridges?
>
> Yes, equality over floating point numbers is complicated by precision
> (e.g., in languages like C and C++, intermediates may arbitrarily be
> kept in extended-precision registers, so that x+y==x+y need not be true)
> and NaN (where NaN==NaN is false).

Well, yes, but all of these problems are already there as soon as you
use pseudo real numbers.  They are not introduced by the use of a map.

Why not have some faith in the future users of the map?  They may know
of these problems and still have a perfectly good reason to use double
or float as map key.

Best regards,
Andre


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

stephan.bergmann
On 03/25/09 14:08, Andre Fischer wrote:

> Stephan Bergmann wrote:
>> On 03/20/09 23:04, Frank Schönheit - Sun Microsystems Germany wrote:
>>> In all other cases, it is at the implementations discretion whether for
>>> a given KeyType, it is possible to put the VOID key into the map.
>>> Strictly, you could say it should not be possible since actually, VOID
>>> is not a value from KeyType's value set. It is "only" that the generic
>>> API ("put( any, any)") allows for VOID keys, where a less generic API
>>> ("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
>>> allow for it.
>>> However, I would not restrict implementations too much, so I preferred
>>> to leave it undecided in the interface definition whether VOID keys (or
>>> values) are accepted.
>>
>> Why special case VOID and not, say, CHAR?
>
> I would prefer not to have special key at all.  The above reasoning
> (put(any,any) allows VOID keys) is true for all types supported by ANY
> and therefore is not really an argument for having a special key.

I think we start to talk past each other here.  I did not want to
discuss demand for a "special key" at all.  Rather, I wanted to discuss
whether arbitrarily allowing VOID keys (but not, say, also CHAR keys) in
addition to properly typed ones makes sense.

>>>> But I get your point: Leave out "unreasonable" types that would lead
>>>> to hassle in the implementations (one might also want to leave out
>>>> float and double, given their peculiarities).
>>>
>>> I am not sure I should dare to ask ... with peculiarities of float and
>>> double, you refer to what? The only thing I can imagine right now is
>>> their ... imprecision, which shouldn't be a problem in this context. Do
>>> they have more issues, perhaps when passed around crossing bridges?
>>
>> Yes, equality over floating point numbers is complicated by precision
>> (e.g., in languages like C and C++, intermediates may arbitrarily be
>> kept in extended-precision registers, so that x+y==x+y need not be
>> true) and NaN (where NaN==NaN is false).
>
> Well, yes, but all of these problems are already there as soon as you
> use pseudo real numbers.  They are not introduced by the use of a map.
>
> Why not have some faith in the future users of the map?  They may know
> of these problems and still have a perfectly good reason to use double
> or float as map key.

I just thought that if Map is already restricted on what key types it
supports, it might make sense to also rule out floating point types (as
supporting them might cause more trouble than it is worth it).  If
anybody thinks differently, fine with me.  (However, if you do support
floating point types, you should clarify what equality relation to use
for them, the one at
<http://udk.openoffice.org/common/man/typesystem.html> that implies
NaN==NaN or the one required by IEEE and implemented by your typical
programming language, where NaN==NaN does not hold.)

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: css.container.XMap

frank.schoenheit
In reply to this post by frank.schoenheit
> FYI: the latest versions:
> http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/XMap.idl
> http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/Map.idl

http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/EnumerableMap.idl
http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/XEnumerableMap.idl
http://svn.services.openoffice.org/ooo/cws/dba32b/udkapi/com/sun/star/container/XMap.idl


Andre convinced me to separate the enumeration functionality from XMap.
While this is effectively inconsistent with the other container
interfaces from css.container, it allows for map implementations which
do not care for the (sometimes non-trivial to specify and implement)
enumerations.

Except the changes requested/described/agreed upon in this thread
already, I now also excluded NaN as key/value for an EnumerableMap.

Comments welcome (kind of :), as always.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]