[gdal-dev] Nullable fields in OGR

[Jason Roberts]

> I'd be careful as abstractions of abstractions can easily lead to
> fat beasts which can do everything, but are complex as hell where
> nobody understands what is what and how it actually works.

I believe I learned this as oopaholism, a disease in which someone becomes
so addicted to object orientation that they spend all of their time working
on frameworks that don't actually DO anything. :-)

Seriously, all I am trying to do is build some tools that can work in
multiple GISes without having rewriting large portions of the tools once for
each GIS. If that, in itself, is pointless or not doable at this moment in
time, then I guess I am crazy.

Jason

-----Original Message-----
From: Mateusz Loskot [mailto:mateusz at loskot.net] 
Sent: Thursday, February 18, 2010 3:23 PM
To: Jason Roberts
Cc: 'gdal-dev'
Subject: Re: [gdal-dev] Nullable fields in OGR

Jason Roberts wrote:
> A while back, Mateusz asked this:
>> Yes. Also, most applications I've seen using OGR do define their own
>> data models and translate OGRFeature to features of their own types.
>> Perhaps it would be interesting to know why they don't use OGRFeature
>> as a part of their data model, what's missing...
>
> I am currently evaluating whether or not I should use OGRFeature directly
> in a data model, or wrap it. Without nullability, I am probably inclined
> to wrap it. As I have mentioned previously on gdal-dev, I'm trying
> to build something that wraps OGR and ArcGIS APIs behind a common
> abstraction, to allow development of tools that work with both.

I have no interest in trying to convince you to not to do it, but my name
appeared, so I feel entitled to share comment.

I'd be careful as abstractions of abstractions can easily lead to
fat beasts which can do everything, but are complex as hell where
nobody understands what is what and how it actually works.

Wrapper, namely adapter pattern, usually means translation of one
interface to another, likely to interface which has common denominator
with something else. It is about structure of software components.

However, translation between interfaces, does not mean translation between
semantics. The latter problem belongs to domain of data models and ORM.
You will most likely have to deal with both problems. The API translation
should be a straightforward task. ORM usually introduces the whole pile of
complexity (see software pieces like FDO).

My point is, I doubt there is a point in developing such thing.

Best regards,
-- 
Mateusz Loskot
http://mateusz.loskot.net