[fdo-internals] FDO RFC 7 - Add New Methods to FdoClassDefinition
dan.stoica at autodesk.com
Fri Jul 27 12:00:05 EDT 2007
"But it is somewhat unfortunate."
Yes, there is Set/GetIsComputed() that sets a precedence. But it is
somehow different, I think. In any case there is no reason to aggravate
How about this alternative solution addressing the problem at hand and
future similar problems:
Define a method Set/GetProviderSettings() which will return bitmapped
enumerators like FDO_PROVIDER_IS_COMPUTED or FDO_PROVIDER_IS_VIEW etc.
Later on, for consistency, we could deprecate Set/GetIsComputed()...
Just a thought,
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Sent: Friday, July 27, 2007 11:10 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 7 - Add New Methods to
Dan Stoica wrote:
> /// Sets the value of m_IsViewBased. It is true if a class
> is based on view; otherwise is false.
> /// This is an internal method that can only be called by
> providers._ Application should not use this method._
> /// \return
> /// Returns nothing
> FDO_API void SetIsViewBased( bool value );
> How do we enforce (see in red) this behavior since the method is
It seems to me we have this pattern quite widely in FDO, don't we?
Properties that should only be set from within the providers but with
the setter methods also exposed to applications.
Personally I can live with this exposure with the expectations
But it is somewhat unfortunate. I can't help but think there might have
been a better way of originally laying this all out.
I set the clouds in motion - turn up | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo,
fdo-internals mailing list
fdo-internals at lists.osgeo.org
More information about the fdo-internals