Nabble - openoffice - interface-discuss

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-08-29T23:19:39Z

Dear sir or madam,
we can wholesale cheap Nike Shoes,wholesale Air Jordan(1-24),wholesale Nike Air Force 08 Low,wholesale Nike Air Force 1 Low Supreme 07,wholesale Nike Obama AF1,wholesale Nike dunks,wholesale cheap Nike Shox,wholesale Nike Air Max,wholesale Air Jordans,wholesale Nike Air Jordan Force Fusion,wholesale New Jordans 2009,wholesale Obama Jordans,wholesale Adidas shoe:Adicolor,Adidas 35, Adidas 2006,Adidas NBA,and wholesale Bape sat shoes,wholesale Puma shoes,and wholesale another Brand shoes: Gucci shoes, D&G shoes,Chanel shoes Timberland shoes Rada shoes, With high quality,as I hope we can have a good start,we cut down our prices to cost level.we have fast shipping about 4-5days and successful exported.we can accept small order,you can see our quality and service. You can look the picture at http://www.Nikesc.com
Best wishes!!!
I will oblige if you early reply.

The new products has already appear on market

http://www.nikesc.comwholesale Nikes,wholesale sneakers,Cheap Jordans,cheap Adidas,cheap Nike dunks,wholesale Jordans,cheap Nikes,cheap Nike shox,cheap Nike shoes,cheap Nike Air force 1,cheap Air Jordans,cheap dunks,cheap Nike sb,cheap Nike sneakers,Retro
discount Nike shoes,cheap Air max,cheap Jordan sneakers,wholesale Jordan Fusion,wholesale Nike Air forceone,
wholesale Nike dunks,Gucci,Prada,jeans,bags,Adidas,Puma,www.Nikesc.com

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-08-23T02:21:50Z

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-08-21T00:13:40Z

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-08-18T23:46:36Z

Re: the mysteriously inconsistent bAbsorb parameter

2009-08-05T22:08:58Z

Michael Stahl wrote:

> the XText interface is inconsistent in its definition of the bAbsorb
> parameter of the methods insertString, insertControlCharacter and
> insertTextContent.
>
> the documentation for insertControlCharacter is silent on the matter.
> insertString says:
>
> http://api.openoffice.org/docs/common/ref/com/sun/star/text/XSimpleText.html#insertString
>
> Parameter bAbsorb
> specifies whether the text spanned by xRange will be replaced. If true
> then the content of xRange will be replaced by aString, otherwise aString
> will be inserted at the beginning of xRange.
>
>
> and insertTextContent:
>
> http://api.openoffice.org/docs/common/ref/com/sun/star/text/XText.html#insertTextContent
>
> Parameter bAbsorb
> specifies whether the text spanned by xRange will be replaced. If true
> then the content of xRange will be replaced by xContent, otherwise
> xContent will be inserted at the end of xRange.
>
>
> so for insertString, it is the beginning of xRange, but for
> insertTextContent, it is the end of xRange.
> apparently this inconsistency also confused the implementer of SwXText in
> writer, because it consistently implements insertion at the start of the
> range in all 3 methods:
>
> http://svn.services.openoffice.org/opengrok/xref/DEV300_m54/sw/source/core/unocore/unotext.cxx#544
>
> 544 xTempRange = xRange->getStart();
>
>
> so, what to do?
> fix the implementation in writer to be inconsistent to match the API
> specification?
> or fix the API specification to consistently refer to the start of xRange?
>

i would prefer to change the API to bring it in a consistent state. It
sounds much more intuitive and cleaner to insert at the beginning in all
three methods.

But it's probably not so easy because this interface is used a lot, see
http://api.openoffice.org/docs/common/ref/com/sun/star/text/XText-xref.html

You have to check some more places ... Maybe we should change it for OOo
4.0, i am not 100% sure.

Juergen

> regards,
> michael
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

the mysteriously inconsistent bAbsorb parameter

2009-08-05T10:12:08Z

the XText interface is inconsistent in its definition of the bAbsorb
parameter of the methods insertString, insertControlCharacter and
insertTextContent.

the documentation for insertControlCharacter is silent on the matter.
insertString says:

http://api.openoffice.org/docs/common/ref/com/sun/star/text/XSimpleText.html#insertString

Parameter bAbsorb
specifies whether the text spanned by xRange will be replaced. If true
then the content of xRange will be replaced by aString, otherwise aString
will be inserted at the beginning of xRange.

and insertTextContent:

http://api.openoffice.org/docs/common/ref/com/sun/star/text/XText.html#insertTextContent

Parameter bAbsorb
specifies whether the text spanned by xRange will be replaced. If true
then the content of xRange will be replaced by xContent, otherwise
xContent will be inserted at the end of xRange.

so for insertString, it is the beginning of xRange, but for
insertTextContent, it is the end of xRange.
apparently this inconsistency also confused the implementer of SwXText in
writer, because it consistently implements insertion at the start of the
range in all 3 methods:

http://svn.services.openoffice.org/opengrok/xref/DEV300_m54/sw/source/core/unocore/unotext.cxx#544

544 xTempRange = xRange->getStart();

so, what to do?
fix the implementation in writer to be inconsistent to match the API
specification?
or fix the API specification to consistently refer to the start of xRange?

regards,
michael

--
"Measuring software productivity by lines of code is like measuring
progress on an airplane by how much it weighs." -- Bill Gates

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-08-05T01:09:15Z

[url=http://www.Nikesc.com]cheap Nikes[/url],[url=http://www.Nikesc.com]cheap Jordan[/url], [url=http://www.Nikesc.com]cheap sneakers[/url]

Dear sir or madam,
we can wholesale cheap Nike Shoes,wholesale Air Jordan(1-24),wholesale Nike Air Force 08 Low,wholesale Nike Air Force 1 Low Supreme 07,wholesale Nike Obama AF1,wholesale Nike dunks,wholesale cheap Nike Shox,wholesale Nike Air Max,wholesale Air Jordans,wholesale Nike Air Jordan Force Fusion,wholesale New Jordans 2009,wholesale Obama Jordans,wholesale Adidas shoe:Adicolor,Adidas 35, Adidas 2006,Adidas NBA,and wholesale Bape sat shoes,wholesale Puma shoes,and wholesale another Brand shoes: Gucci shoes, D&G shoes,Chanel shoes Timberland shoes Rada shoes, With high quality,as I hope we can have a good start,we cut down our prices to cost level.we have fast shipping about 4-5days and successful exported.we can accept small order,you can see our quality and service. You can look the picture at http://www.Nikesc.com
Best wishes!!!
I will oblige if you early reply.

The new products has already appear on market

Cheap Air Jordans,Nikes Adidas shoes,cheap Puma Gucci shoes,ATO shoes,cheap Prada shoes,cheap jeans

2009-07-18T18:46:45Z

Dear Customers
Nikesc Global Trade Co.LTD,is a leading brand sports shoes wholesaler in China.It has a wide range wholesale of Nike,Nike Max series,Nike shox,Air Jordan,Jordan Fusion,Air force one, Dunk, Bapesta,Adidas,Gucci,Timberland boots etc to offer.We also supply brand bags and fashion clothes, jeans. All the shoes are packed with original boxes with retro cards, and the tags. We try our best to provide you with good quality and competitive price. The number of your order starts from one.Hope to hear from your reply. We have confidence that you will be 100% satisfied with products. We are looking forward to doing business with you.
If you are interested in our shoes,please feel free to contact us.
Contact Person : leiwen

pls link google search (Nikesc.com)
http://www.Nikesc.com
E-mail:nikesc@live.cn

Cheap Adidas,Puma,Bape,D&G Shoes,Cheap Gucci shoes,Hogan Shoes,cheap Lv Shoes,Chanel Shoes,Cheap Timberland boots

2009-07-05T19:33:14Z

Dear Sir or Madam
Wholesale here are:Nike Sneakers including cheap Nike sneakers,Nike basketball sneakers,
Womens Nike sneakers,Rare Nike sneakers, Rare Nike sneakers,Nike Retro snakers,Exlusive Nike sneakers,you can get wholesale Nike sneaker's price with discount for cheap Nike shoes and cheap Nike sneakers.
we keep updating latest styles and stocks every day,if there are on the stocks,drop shipping business is also welcome.At the same time,we also accept small order to satisfy all customers.One pair is the mini order for all our goods.
If you are interested in our products,don't hesitate to contact us.
pls link google search (Nikesc.com)

http://www.Nikesc.com

Re: [api-dev] adding a method to a published interface

2009-06-30T04:39:08Z

I disagree with doing "selected" enhancements in single css.awt interfaces.

All API in css.awt is "broken", because someone made the decision there
shouldn't be get- methods, because they are "evil".

Some background: - css.awt was one of the first APIs we ever created,
with first version of UNO, and the main intent was a remote client,
where get methods are very expensive, because they can't be called
oneway and would block further program execution until they return.

This is why the API is how it is... :(

If people agree on incompatible changes, I would prefer to clean up all
css.awt API and add missing get- methods.

I wouldn't start to do it "here and there" when somebody stumbles over
it. And the next change, and one change again, one more, ...

But a full cleanup probably really would need to wait for a major
version (and an agreement on incompatible changes).

Malte.

Frank Schönheit - Sun Microsystems Germany wrote, On 06/29/09 12:43:

> Hi,
>
> would adding a method to an existing published interface be considered
> too incompatible for a 3.2 release?
>
> In particular, css.awt.XView has a method setZoom, but not a getZoom,
> which I'd like to add. I could create a crutch called XView2, deriving
> from XView, having only this one said method. However, it would lead to
> a better API (IMO), if we would simply add the method to XView.
>
> Now XView is "published", but did't we say that there's a certain type
> of incompatible API changes which we should consider to allow for
> non-major OOo releases?
>
> In this particular case, I'd say this is such a case: The change makes
> the interface more consistent, allows retrieving information which
> otherwise cannot be retrieved (via UNO), and touches an interfaces which
> is rarely used inside OOo's code base (and probably also rarely outside
> of it).
>
> Opinions?
>
> Ciao
> Frank
>
> x-post to interface-discuss and dev@api, follow-up to dev@api
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

adding a method to a published interface

2009-06-29T03:43:27Z

Hi,

would adding a method to an existing published interface be considered
too incompatible for a 3.2 release?

In particular, css.awt.XView has a method setZoom, but not a getZoom,
which I'd like to add. I could create a crutch called XView2, deriving
from XView, having only this one said method. However, it would lead to
a better API (IMO), if we would simply add the method to XView.

Now XView is "published", but did't we say that there's a certain type
of incompatible API changes which we should consider to allow for
non-major OOo releases?

In this particular case, I'd say this is such a case: The change makes
the interface more consistent, allows retrieving information which
otherwise cannot be retrieved (via UNO), and touches an interfaces which
is rarely used inside OOo's code base (and probably also rarely outside
of it).

Opinions?

Ciao
Frank

x-post to interface-discuss and dev@api, follow-up to dev@api

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: constant and enum

2009-06-19T04:36:26Z

Hi Eike,

>> We would need to explicitly check this, but in my understanding the only
>> language binding where this is (compile-time) incompatible is C++. In
>> Java, it should be compile-time compatible, and perhaps even
>> runtime-compatible. All other language bindings should be completely
>> agnostic of such a change.
>
> If I understood correctly back years ago, changing an enum is not
> possible because in Java there is the Enum object that bails out if the
> value encountered during runtime doesn't match the set declared at
> compile time.

Interesting. Okay, this would be a point *against* extending an enum -
at least against changing it too easily.

However, seeing the bunch of Foo2 types introduced by that in the given
case, it might be ... yes yes yes, shutting up now :)

Thanks & Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

constant and enum (was: [interface-discuss] Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2)

2009-06-19T04:11:36Z

Hi Frank,

On Thursday, 2009-06-18 10:40:15 +0200, Frank Schönheit wrote:

> In the concrete case, I think replacing the enum with an (extensible)
> constant group is better than introducing the FilterOperator2, which
> just adds clutter to the API.
>
> We would need to explicitly check this, but in my understanding the only
> language binding where this is (compile-time) incompatible is C++. In
> Java, it should be compile-time compatible, and perhaps even
> runtime-compatible. All other language bindings should be completely
> agnostic of such a change.

If I understood correctly back years ago, changing an enum is not
possible because in Java there is the Enum object that bails out if the
value encountered during runtime doesn't match the set declared at
compile time. Someone correct me if I'm wrong on this or there are
details to add.

> > Wouldn't it make sense to specify that constant groups are extensible
> > per se, so that each code dealing with them must be able to handle
> > unknown values? Perhaps with giving hints or specifying how unknown
> > values of a particular group should be treated?
>
> Yes, would be a reasonable general guideline. Not sure we have a place
> for such guidelines, though.

Code implementing an API and dealing with constants or enums should
always have some default case to handle unknown values. If there's
a recommended treatment of unknown values in a specific constant group
or API using it, that should of course be documented in the IDL.

> > So constant groups could be changed at any time with good confidence,
> > without considering this to be "incompatible". Without this explicit
> > declaration adding constants to groups actually is incompatible, though
> > we didn't AFAIK consider it to be so when we already added numerous
> > constants to several groups.
>
> Does our watch dog bite when adding new constants to a *published*
> group?

No, it doesn't. Already did that. For obvious reasons just don't change
the value of an already existing constant. While syntactically doesn't
make it barf, it would create semantical confusion.

Long story short: I don't introduce new enums anymore but use constants
instead. This is ugly because you lose type safety of enums and maybe
other benefits, but for the penalty of not being able to add new values
it just isn't worth the hassle.

Eike

--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to the erl@... account, which I use for
mailing lists only and don't read from outside Sun. Use erack@... Thanks.

attachment0 (196 bytes) Download Attachment

wholesale Nikes Dunks,cheap Jordans,Air Max,cheap Nike Shox,cheap Adidas shoes,shorts jeans,UGG boots

2009-06-19T03:03:48Z

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T10:02:48Z

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Mathias,
>
>> Yes, even published constant groups were allowed to be changed,
>
> didn't know that ....
>
>> but IMHO
>> the problems caused by that (or not caused by that) are the same as in
>> case of enums. We treated them differently, though there is no technical
>> reason. No language binding today would have a technical problem with an
>> extended enum as none of them really does boundary checks and breaks if
>> a "new" enum value is found (even C++).
>
> In the C++ language binding, a "Foo_MAKE_FIXED_SIZE = SAL_MAX_ENUM" is
> generated for a enum type Foo. IIRC, this was introduced a few years
> ago, because of anticipated or real problems with the enum size ...

But where is it used? This is just a crutch because C++ does not have
this built-in. If the crutch is not used anywhere...

Ciao,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T05:15:00Z

Hi Mathias,

> Yes, even published constant groups were allowed to be changed,

didn't know that ....

> but IMHO
> the problems caused by that (or not caused by that) are the same as in
> case of enums. We treated them differently, though there is no technical
> reason. No language binding today would have a technical problem with an
> extended enum as none of them really does boundary checks and breaks if
> a "new" enum value is found (even C++).

In the C++ language binding, a "Foo_MAKE_FIXED_SIZE = SAL_MAX_ENUM" is
generated for a enum type Foo. IIRC, this was introduced a few years
ago, because of anticipated or real problems with the enum size ...

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T02:36:06Z

Frank Schönheit - Sun Microsystems Germany wrote:

>> So constant groups could be changed at any time with good confidence,
>> without considering this to be "incompatible". Without this explicit
>> declaration adding constants to groups actually is incompatible, though
>> we didn't AFAIK consider it to be so when we already added numerous
>> constants to several groups.
>
> Does our watch dog bite when adding new constants to a *published*
> group? Never tried. Adding new constants to an unpublished group has
> never been a problem, by definition and in theory, since they were
> allowed to be changed incompatibly.

Yes, even published constant groups were allowed to be changed, but IMHO
the problems caused by that (or not caused by that) are the same as in
case of enums. We treated them differently, though there is no technical
reason. No language binding today would have a technical problem with an
extended enum as none of them really does boundary checks and breaks if
a "new" enum value is found (even C++). OTOH we can't exclude that any
future language binding might do that, but that is true for constant
groups also.

To avoid uncertainties I thought it might be a good idea to make it
clear that constant groups may be extended without considering that an
incompatible change and that all language bindings (and API users) must
take that into account, while enum changes are always seen as incompatible.

Strictly speaking, wanting to change an enum is a clear sign that this
type never should have been an enum in the first place. The
recommendation always was that the enum type should be used only for
enumerations that can be seen as fixed if only probable or forseeable
changes of the world around us are considered. Thus weekdays, month
names etc. are good candidates as odds are high that they don't change
in the life time of our API. ;-) Many enums in our API are wrong, it
seems that enum or constant group was chosen at random (e.g. in the
toolkit API).

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T02:20:54Z

Hi Niklas,

>> In the concrete case, I think replacing the enum with an (extensible)
>> constant group is better than introducing the FilterOperator2, which
>> just adds clutter to the API.
>
> The FilterOperator2 constants group contains the old and new operators,
> the TableFilterField2 struct contains an integer instead of the
> FilterOperator enum, and the XSheetFilterDescriptor2 interface can be
> used instead of XSheetFilterDescriptor.
>
> So, "replacing the enum with an constant group" is exactly what was
> done, keeping the old types for compatibility.

okay, my wording might not have been precise enough, "keeping the
replaced item" is not my definition of "replace", but of "add" :)

I explicitly suggest to sacrifice compatibility, and gain a cleaner API.
Having a FilterOperator2, and the respective changes in all interfaces
and implementations which in/directly use it, is ugly, to say at least.

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T02:05:30Z

On 06/18/09 10:40, Frank Schönheit - Sun Microsystems Germany wrote:
> In the concrete case, I think replacing the enum with an (extensible)
> constant group is better than introducing the FilterOperator2, which
> just adds clutter to the API.

The FilterOperator2 constants group contains the old and new operators,
the TableFilterField2 struct contains an integer instead of the
FilterOperator enum, and the XSheetFilterDescriptor2 interface can be
used instead of XSheetFilterDescriptor.

So, "replacing the enum with an constant group" is exactly what was
done, keeping the old types for compatibility.

Niklas

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-18T01:40:15Z

Hi Mathias,

> To my knowledge we still didn't agree on doing incompatible changes
> before 4.0.

Right, we only agreed to disagree :)

In the concrete case, I think replacing the enum with an (extensible)
constant group is better than introducing the FilterOperator2, which
just adds clutter to the API.

We would need to explicitly check this, but in my understanding the only
language binding where this is (compile-time) incompatible is C++. In
Java, it should be compile-time compatible, and perhaps even
runtime-compatible. All other language bindings should be completely
agnostic of such a change.

Well, Stephan could probably point out some esoteric cases where this
breaks ... Glad^Wsad he's on vacation currently :)

> BTW: while changing enums currently is impossible without getting bitten
> by our API compatibility watch dog, IIRC it tolerates extensions of
> constant groups. Please correct me if I'm wrong.

You aren't, to my knowledge.

> Wouldn't it make sense to specify that constant groups are extensible
> per se, so that each code dealing with them must be able to handle
> unknown values? Perhaps with giving hints or specifying how unknown
> values of a particular group should be treated?

Yes, would be a reasonable general guideline. Not sure we have a place
for such guidelines, though.

> So constant groups could be changed at any time with good confidence,
> without considering this to be "incompatible". Without this explicit
> declaration adding constants to groups actually is incompatible, though
> we didn't AFAIK consider it to be so when we already added numerous
> constants to several groups.

Does our watch dog bite when adding new constants to a *published*
group? Never tried. Adding new constants to an unpublished group has
never been a problem, by definition and in theory, since they were
allowed to be changed incompatibly.

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-17T11:19:19Z

Hi Thomas,

> I discussed this issue some time ago with our UNO experts.
> The result was that extending an UNO enum is unacceptable.

Ah ...

For what reasons? Just curious whether those reasons still hold now that
we said incompatible API changes are allowed, if done carefully.

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-17T10:20:27Z

Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Thomas,
>
>> *Description*
>> -------------
>> The com::sun::star::sheet::FilterOperator2 constants extend the
>> com::sun::star::sheet::FilterOperator enum
>
> Since we recently reached an agreement that incompatible UNO API changes
> are not bad by definition (but only if done improperly), wouldn't this
> be a good chance to stress this new freedom, and extend the
> FilterOperator enum, instead of this somewhat strange construct of
> extending the /enum/ with a /constants group/ FilterOperator2?

To my knowledge we still didn't agree on doing incompatible changes
before 4.0.

BTW: while changing enums currently is impossible without getting bitten
by our API compatibility watch dog, IIRC it tolerates extensions of
constant groups. Please correct me if I'm wrong. But in practice,
constant groups and enums are equally prone to compatibility problems.
If code is confronted with an unknown constant - in the firm belief that
this can't happen as it wasn't specified at the time when the code was
written - bad things can happen.

Wouldn't it make sense to specify that constant groups are extensible
per se, so that each code dealing with them must be able to handle
unknown values? Perhaps with giving hints or specifying how unknown
values of a particular group should be treated?

So constant groups could be changed at any time with good confidence,
without considering this to be "incompatible". Without this explicit
declaration adding constants to groups actually is incompatible, though
we didn't AFAIK consider it to be so when we already added numerous
constants to several groups.

Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba@...".
I use it for the OOo lists and only rarely read other mails sent to it.

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-17T06:20:15Z

I discussed this issue some time ago with our UNO experts.
The result was that extending an UNO enum is unacceptable.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: [interface-announce] info/CWS calc51 : New constants com::sun::star::sheet::FilterOperator2

2009-06-17T05:58:37Z

Hi Thomas,

> *Description*
> -------------
> The com::sun::star::sheet::FilterOperator2 constants extend the
> com::sun::star::sheet::FilterOperator enum

Since we recently reached an agreement that incompatible UNO API changes
are not bad by definition (but only if done improperly), wouldn't this
be a good chance to stress this new freedom, and extend the
FilterOperator enum, instead of this somewhat strange construct of
extending the /enum/ with a /constants group/ FilterOperator2?

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Sitz der Gesellschaft: -
- Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten -
- Amtsgericht München: HRB 161028 -
- Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel -
- Vorsitzender des Aufsichtsrates: Martin Häring -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Cheap Adidas,Puma,Bape,D&G Shoes,Cheap Gucci shoes,Hogan Shoes,cheap Lv Shoes,Chanel Shoes,Cheap Timberland boots

2009-06-09T01:34:15Z

Dear Customers
welcome to visit our website: http://www.Nikesc.com , http://www.sneakermonger.com I'm glad to introduce ourselves as a good wholesaler of sneakers, apparels, with high quality, best service and reasonable price in china. We can offer series of cheap Nike Jordan,cheap cheap Jordan fusion,cheap Nike Shox,cheap Air Force One,cheap Air max,cheap Gucci shoes,
cheap Puma shoes,cheap Timberland boots,cheap LV shoes,cheap prada shoes,cheap D&G shoes,
cheap Bape shoes etc.We also wholesale cheap handbags such as chanel,Coach,Fendi,Gucci,LV, Prada.wholesale cheap Jeans such as Red monkey,Evisu,Bape,BBC,Ed hardy,D&G,Antik,G-star,
Antruletc. The price depends on quantity.All of the products displayed on our website are available and in stock.
The products you ordered will be delivered by DHL, EMS, within 24 hours after your payment. Our payment terms are Western Union and Paypal. On the other hand, the freight is FREE. We are sincerely to find excellent partners to establish long-term business relationships. If you are interested in our products, please do not hesitate to contact us, we are on the service for you. Please contact us for more details.
Website: http://www.Nikesc.com
E-mail:nikesc@live.cn

Wholesale cheap Jordans sneakers,cheap Air Max,Obama shoes,cheap Nike Shox,cheap Adidas shoes,cheap Puma shoes

2009-05-28T21:28:31Z

[url=http://www.Nikesc.com]cheap Nikes[/url],[url=http://www.Nikesc.com]cheap Jordan[/url],
[url=http://www.Nikesc.com]cheap sneakers[/url]

Dear Customers
welcome to visit our website: http://www.Nikesc.com , http://www.sneakermonger.com I'm glad to introduce ourselves as a good wholesaler of sneakers, apparels, with high quality, best service and reasonable price in china. We can offer series of cheap Nike Jordan,cheap cheap Jordan fusion,cheap Nike Shox,cheap Air Force One,cheap Air max,cheap Gucci shoes,
cheap Puma shoes,cheap Timberland boots,cheap LV shoes,cheap prada shoes,cheap D&G shoes,
cheap Bape shoes etc.We also wholesale cheap handbags such as chanel,Coach,Fendi,Gucci,LV, Prada.wholesale cheap Jeans such as Red monkey,Evisu,Bape,BBC,Ed hardy,D&G,Antik,G-star,
Antruletc. The price depends on quantity.All of the products displayed on our website are available and in stock.
The products you ordered will be delivered by DHL, EMS, within 24 hours after your payment. Our payment terms are Western Union and Paypal. On the other hand, the freight is FREE. We are sincerely to find excellent partners to establish long-term business relationships. If you are interested in our products, please do not hesitate to contact us, we are on the service for you. Please contact us for more details.
Website: http://www.Nikesc.com
http://www.sneakermonger.com

Re: Re: [allsvn] r271808 - cws/fwk103/sal/inc/osl

2009-05-13T04:32:06Z

On 05/13/09 12:13, Frank Schönheit - Sun Microsystems Germany wrote:
> How is a macro declared as private?

By documenting it so. ;) (Preferably with a plain C/C++ comment, not a
autodoc-style one, so that it does not show up in the autodoc-generated
documentation at all.)

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [allsvn] r271808 - cws/fwk103/sal/inc/osl

2009-05-13T03:13:43Z

Hi Mikhail,

>> I must confess, I am not familiar with URE interface handling process,
>> how can I declare a macro private? I see no similar declaration for
>> other macros.
> As we have discussed per phone, I will declare all the new macros as
> private

Hey, if you ask such interesting questions in public, please also put
the answer here :)
How is a macro declared as private?

Ciao
Frank

--
- Frank Schönheit, Software Engineer frank.schoenheit@... -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: Re: [allsvn] r271808 - cws/fwk103/sal/inc/osl

2009-05-13T02:23:02Z

Hi,

On 05/13/09 10:34, Mikhail Voytenko wrote:

>>
>> It should be document which of those new macros are part of the
>> stable URE interface (including @since tags) and which are private.
>>
>> This is especially true for OSL_TO_STRING and
>> OSL_MACRO_VALUE_TO_STRING, which are useful in various places, but if
>> added to the stable URE interface should probably go into a more
>> general header than osl/diagnose.h.
> I will move the mentioned two macros to sal/macros.h ( with using SAL_
> prefix ) then and document all the new macros with @since tag.
>
> I must confess, I am not familiar with URE interface handling process,
> how can I declare a macro private? I see no similar declaration for
> other macros.

As we have discussed per phone, I will declare all the new macros as
private for now, since they are intended to be used in the office only.
The move of the macros is also not necessary in this case.

If there will be a necessity to publish the macros in future we still
can do it.

Best regards,
Mikhail.

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: [allsvn] r271808 - cws/fwk103/sal/inc/osl

2009-05-13T01:34:31Z

Hi Stephan,

Please see my comments inline.

On 05/12/09 17:30, Stephan Bergmann wrote:

> On 05/12/09 11:43, mav@... wrote:
>> Author: mav
>> Date: Tue May 12 09:39:38 2009
>> New Revision: 271808
>>
>> Log:
>> #i101356# allow to generate a small log if a document can not be stored
>>
>> Modified:
>> cws/fwk103/sal/inc/osl/diagnose.h
>>
>> Modified: cws/fwk103/sal/inc/osl/diagnose.h
>> ==============================================================================
>>
>> --- cws/fwk103/sal/inc/osl/diagnose.h Tue May 12 09:38:00 2009
>> (r271807)
>> +++ cws/fwk103/sal/inc/osl/diagnose.h Tue May 12 09:39:38 2009
>> (r271808)
>> @@ -80,6 +80,23 @@
>>
>> #define OSL_THIS_FILE __FILE__
>>
>> +#ifdef __func__
>> +#define OSL_THIS_FUNC __func__
>> +#elifdef __PRETTY_FUNCTION__
>> +#define OSL_THIS_FUNC __PRETTY_FUNCTION__
>> +#elifdef __FUNCTION__
>> +#define OSL_THIS_FUNC __FUNCTION__
>> +#else
>> +#define OSL_THIS_FUNC " "
>> +#endif
>> +
>> +#define OSL_TO_STRING( x ) #x
>> +#define OSL_MACRO_VALUE_TO_STRING( x ) OSL_TO_STRING( x )
>> +#define OSL_STRING_LINE OSL_MACRO_VALUE_TO_STRING( __LINE__ )
>> +
>> +#define OSL_LOG_PREFIX OSL_THIS_FILE ":" OSL_THIS_FUNC ":"
>> OSL_STRING_LINE
>> +#define OSL_LOG_CONSTSTRING( m ) OSL_LOG_PREFIX "; " m
>
> It should be document which of those new macros are part of the stable
> URE interface (including @since tags) and which are private.
>
> This is especially true for OSL_TO_STRING and
> OSL_MACRO_VALUE_TO_STRING, which are useful in various places, but if
> added to the stable URE interface should probably go into a more
> general header than osl/diagnose.h.

I will move the mentioned two macros to sal/macros.h ( with using SAL_
prefix ) then and document all the new macros with @since tag.

I must confess, I am not familiar with URE interface handling process,
how can I declare a macro private? I see no similar declaration for
other macros.

>
>
> From the "crusade to eliminate every excess macro" camp point of view:
> 1 The use of OSL_STRING_LINE could be inlined in OSL_LOG_PREFIX, and
> OSL_STRING_LINE dropped.
Yes, you are right, OSL_MACRO_VALUE_TO_STRING is probably enough. I
shall change it.

> 2 Would it work to move the "; " from OSL_LOG_CONSTSTRING to
> OSL_LOG_PREFIX, and drop OSL_LOG_CONSTSTRING?
The pattern 'OSL_LOG_PREFIX "Message"' looked not so readable for me
than 'OSL_LOG_CONSTSTRING( "Message" )'.
The last one looks very similar to the very common one
RTL_CONSTASCII_USTRINGPARAM().

But from other side, it could be treated as excess macro and if somebody
needs it we can add it later. I shall remove it as well.

Thanks,
Mikhail.
>
> -Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Re: [allsvn] r271808 - cws/fwk103/sal/inc/osl

2009-05-12T08:30:22Z

On 05/12/09 11:43, mav@... wrote:

> Author: mav
> Date: Tue May 12 09:39:38 2009
> New Revision: 271808
>
> Log:
> #i101356# allow to generate a small log if a document can not be stored
>
> Modified:
> cws/fwk103/sal/inc/osl/diagnose.h
>
> Modified: cws/fwk103/sal/inc/osl/diagnose.h
> ==============================================================================
> --- cws/fwk103/sal/inc/osl/diagnose.h Tue May 12 09:38:00 2009 (r271807)
> +++ cws/fwk103/sal/inc/osl/diagnose.h Tue May 12 09:39:38 2009 (r271808)
> @@ -80,6 +80,23 @@
>
> #define OSL_THIS_FILE __FILE__
>
> +#ifdef __func__
> +#define OSL_THIS_FUNC __func__
> +#elifdef __PRETTY_FUNCTION__
> +#define OSL_THIS_FUNC __PRETTY_FUNCTION__
> +#elifdef __FUNCTION__
> +#define OSL_THIS_FUNC __FUNCTION__
> +#else
> +#define OSL_THIS_FUNC " "
> +#endif
> +
> +#define OSL_TO_STRING( x ) #x
> +#define OSL_MACRO_VALUE_TO_STRING( x ) OSL_TO_STRING( x )
> +#define OSL_STRING_LINE OSL_MACRO_VALUE_TO_STRING( __LINE__ )
> +
> +#define OSL_LOG_PREFIX OSL_THIS_FILE ":" OSL_THIS_FUNC ":" OSL_STRING_LINE
> +#define OSL_LOG_CONSTSTRING( m ) OSL_LOG_PREFIX "; " m

It should be document which of those new macros are part of the stable
URE interface (including @since tags) and which are private.

This is especially true for OSL_TO_STRING and OSL_MACRO_VALUE_TO_STRING,
which are useful in various places, but if added to the stable URE
interface should probably go into a more general header than osl/diagnose.h.

From the "crusade to eliminate every excess macro" camp point of view:
1 The use of OSL_STRING_LINE could be inlined in OSL_LOG_PREFIX, and
OSL_STRING_LINE dropped. 2 Would it work to move the "; " from
OSL_LOG_CONSTSTRING to OSL_LOG_PREFIX, and drop OSL_LOG_CONSTSTRING?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: interface-discuss-unsubscribe@...
For additional commands, e-mail: interface-discuss-help@...

Wholesale Nikes Jordans sneakers,cheap Air Max,Obama shoes,cheap Nike dunks AF1,Adidas shoes,cheap Puma shoes

2009-05-12T03:15:28Z

[url=http://www.Nikesc.com]cheap Nikes[/url],[url=http://www.Nikesc.com]cheap Jordan[/url], [url=http://www.Nikesc.com]cheap sneakers[/url]

Dear sir or madam,
we can supply Nike Shoes,Air Jordan(1-24),Nike Air Force 08 Low,Nike Air Force 1 Low Supreme 07,Nike Obama AF1,Nike dunks,Nike Shox,Nike Air Max,Air Jordans,Nike Air Jordan Force Fusion,New Jordans 2009,Obama Jordans,Adidas shoe:Adicolor,Adidas 35, Adidas 2006,Adidas NBA,Bape sat shoes, Puma shoes, Brand shoes: Gucci shoes, D&G shoes,Chanel shoes Timberland shoes Rada shoes, With high quality,as I hope we can have a good start,we cut down our prices to cost level.we have fast shipping about 4-5days and successful exported.we can accept small order,you can see our quality and service. You can look the picture at http://www.Nikesc.com , http://www.sneakermonger.com
Best wishes!!!
I will oblige if you early reply.

The new products has already appear on market

Wholesale Nikes Jordans sneakers,cheap Air Max,Obama shoes,cheap Nike dunks AF1,Adidas shoes,cheap Puma shoes

2009-04-25T00:36:14Z

[url=http://www.Nikesc.com]wholesale Nikes[/url],[url=http://www.Nikesc.com]cheap Jordans[/url],[url=http://www.Nikesc.com]cheap sneakers[/url]

Dear Sir or Madam
We are a professional shoes and sneaker industrial company,and as a famous Nike shoes factory and stores and wholesale company.
We Lies in the nike sports shoes factory base with stores in China.We specialised in Brand shoes.Our main business is wholesale Nike shoes and sneakers.
Our factory wholesale Nike shoes style include: Nike Sneakers, Jordan sneakers, Air Force one ,Nike air max,Nike shox,Nike air jordan,Jordan Fusion, nike dunks SB and bape shoes.
We also wholesale other brands of Puma,Timberland,Adidas,Prada etc.Meanwhile,brand clothes (t-shirts,hoodies,jacket),brand handbags,brand jeans and brand sun-glasses.Our policy is: buy more save more.If buy more,we wil give you more discount.We insist that the customers is king.Kindly let us know your interest and we will send you photo samples and quotations for your reference.More information about us.

Contact Person:Leiwen
Please link Google search (Nikesc.com)
http://www.Nikesc.com
http://www.sneakermonger.com
E-mail:nikesc@live.cn

Wholesale Nikes Jordans sneakers,cheap Air Max,Obama shoes,cheap Nike dunks AF1,Adidas shoes,cheap Puma shoes

2009-04-20T22:02:31Z

[url=http://www.Nikesc.com]wholesale Nikes[/url],[url=http://www.Nikesc.com]cheap Jordans[/url],[url=http://www.Nikesc.com]cheap sneakers[/url]

Dear Sir or Madam
Nikesc Global Trade Co.LTD is a top Nike shoes wholesale company. As a big Nike cheap shoes wholesale company,We Sale and Wholesale Nike Shoes from our Nike factory to the Global Nike shop and Nike store. We sale and wholesale Nike shoes as following:Nike Shox,Nike Air Jordan,Nike Air dunks,Nike Air force one,New Jordans 2009,Obama Jordans,Air Max shoes, Nike stocks shoes, Nike sneakers,Nike running shoes,Nike basketball Shoes, Nike discount shoes,Nike cheap Shoes,footwear,sports Shoes,Nike walking shoes,Nike training shoes,Retro Nike shoes,cheap Nike shoes,original Nike shoes, authentic Nike shoes,clear Nike shoes.Brand shoes wholesale: Adidas,Puma,Prada,Timberland, Gucci,Bape STA,LV,UGG,
Fendi,Chanel,D&G,ATO,and so on.
we keep updating latest style and stocks every day, if there are on the stocks,drop shipping business is also welcome.At the same time,we also accept small order to satisfy all customers.One pair is the mini order for all our goods.
If you are interested in our products,don't hesitate to contact us.
pls link Google search (Nikesc.com)

http://www.Nikesc.com
http://www.sneakermonger.com
E-mail:nikesc@live.cn

Wholesale Cheap Jordans sneakers,Air Max,Cheap Nikes Shox dunks,Adidas shoes,cheap Puma Dsquared Shoes,shorts jeans

2009-04-17T01:48:37Z

[url=http://www.Nikesc.com]cheap Nikes[/url],[url=http://www.Nikesc.com]cheap Jordan[/url],
[url=http://www.Nikesc.com]cheap sneakers[/url]

Dear Customers
welcome to visit our website: http://www.Nikesc.com , http://www.sneakermonger.com I'm glad to introduce ourselves as a good wholesaler of sneakers, apparels, with high quality, best service and reasonable price in china. We can offer series of Nike Jordan,Jordan fusion, Nike Shox, Air Force One,Air max,Gucci,Puma,Timberland,LV,prada,D&G,Bape shoes etc.We also supply handbags such as chanel,Coach,Fendi,Gucci,LV, Prada. Jeans such as Red monkey,Evisu,
Bape,BBC,Ed hardy,D&G,Antik,G-star,Antruletc. The price depends on quantity.All of the products displayed on our website are available and in stock.
The products you ordered will be delivered by DHL, EMS, within 24 hours after your payment. Our payment terms are Western Union and Paypal. On the other hand, the freight is FREE. We are sincerely to find excellent partners to establish long-term business relationships. If you are interested in our products, please do not hesitate to contact us, we are on the service for you. Please contact us for more details.
Website: http://www.Nikesc.com
http://www.sneakermonger.com