Table and Query Classes good or unnecessary?
this is a nice way to put it.
ultimately .. people can use any language in any way they want. we still discover features in Studio that make me go — I wish I’d done it that way years ago. The importance, I think you are saying, is to avoid dogma and that no one way is right, as long as you appreciate the reasons why you do it your way, and that another approach has benefits, and even a mixed approach has them too.
heck, even in the english language, new words and methods are created that make it easier to communicate. its jus so sad that my kids use it in a way that I don’t always understand, being an old schooler and that. LOL, ROFL, meme, and on.
Grin. (I like that one).
see you at the third annual users conference
> On Mar 4, 2018, at 10:08 PM, Clifford Ilkay <firstname.lastname@example.org> wrote:
> On Sun, Mar 4, 2018 at 6:18 PM, Bastiaan Olij <email@example.com> wrote:
>> P.S. one thing that I think must be underlined is that while I love
>> Object Orientation, I don’t necessarily find it the only true great path.
> I was reading an article recently about how ludicrous it is that we are
> still having the same fights over which is better, functional programming
> or object-oriented programming. The funny thing is that the OO camp isn’t
> uniform in thought either. They have spirited debates over inheritance vs
> composition with some languages or frameworks favouring one or the other. I
> see merits and shortcomings in all of them.
> I don’t know if Omnis allows object composition but it certainly enables
> one to program in a functional style and it enables one to do OO
> programming via inheritance.
> As I read about query classes, it seems like it can be considered to be a
> “do-it-yourself object relational mapper”. I love ORMs. I’m most familiar
> with the Django ORM. I rarely have to write SQL. When I’m writing Python,
> I’m thinking in terms of Python objects and the Django ORM enables me to
> think in terms of persisting instances of Python objects and fetching and
> manipulating object instances that had been previously stored. I don’t have
> to switch mental gears. In the event I want to write raw SQL, I can do so.
> It seems like query classes provide a higher level of abstraction so that
> you don’t have to think in terms of rows, columns but you’re thinking of
> Omnis objects. If you could forget for a moment that you, or someone else,
> created those query classes by encapsulating SQL, you could say that Omnis
> has an ORM. Creating an ORM is well within the capabilities of engineering.
> Providing that level of abstraction so that you, the Omnis developer, would
> only have to think about persisting, fetching, updating, deleting Omnis
> objects without having to touch or even know about SQL, though you would
> have the option of doing that if you wanted to. That suggests to me that
> this high-level abstraction could be the same regardless of whether the
> back end is Omnis NDF, some SQL database, or even a NoSQL database. You may
> want to request this an Omnis enhancement. 🙂
> Clifford Ilkay
> +1 647-778-8696
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:firstname.lastname@example.org