[wp-hackers] Meta tables: Take 5
mikeschinkel at newclarity.net
Mon Jul 27 15:25:04 UTC 2009
LOL, what a typo!
"When that pattern dies, " should have been "When that pattern does
WordPress Custom Plugins
On Jul 27, 2009, at 10:57 AM, Mike Schinkel wrote:
> Thanks for that long answer, but I still did not hear a viable
> alternate to CRUD, only some hypothetical panacea.
> In my development experience (which spans 20 years now) I've gone
> from strong believing in abstracted solutions to learned belief that
> abstraction for abstraction sake is bad and it's better to stay
> closer to the metal unless and until a true pattern emerges. When
> that pattern dies, it should ideally implement in the language (i.e.
> the "foreach" iteration pattern vs. "for" with counter variables) or
> it that can't happen then in language's library or lastly in a
> framework like WordPress' core. As far as I can see, the only true
> pattern visible is CRUD. Something better may come along but I have
> yet to see it.
> Simpler is better.
> -Mike Schinkel
> WordPress Custom Plugins
> On Jul 27, 2009, at 3:17 AM, Jacob Santos wrote:
>> What is good is not requiring the user of the API to realize the DB
>> table scheme or understand how the DB table works. I think the
>> Taxonomy API is a good example, if the whole concept wasn't so
>> difficult to understand in the first place. I think the better
>> solution is to abstract the DB entirely from the API user and build
>> the API that is built on top of it.
>> The problem I have with CRUD, is that it forces the developer to
>> know the DB scheme or at least understand the scheme. It seems to
>> be taking the easy way out, "Well, I could create an API that
>> doesn't force the developer using the API to know anything about
>> the scheme, but meh, I lika the shiny and don't want to spend too
>> much time developing something."
>> In my experience, it requires the user of the API to know too much
>> information is not important. Likewise, if the Scheme changes, then
>> the API must change and all code that uses CRUD most change as
>> well. If you are trying to create an API that doesn't require
>> hassling the developer working on the API and the user of the API
>> to keep up with the changes, then why use something that either
>> puts the workload on the user ("Oh crap, the API breaks backward
>> compatibility again because of scheme changes.") or on the
>> developer ("Well, I could make refactor the design to where it
>> doesn't suck, but doing so will either break backwards
>> compatibility or cause me to work around a lot of my previous
>> scheme and coding mistakes.").
>> As for the proper solution, I've yet to find one that doesn't
>> suffer from similar flaws or new ones. BREAD suffers from the same
>> reasons of CRUD. I've discovered that the architecture should be a
>> layer on top of the DB that abstracts the table scheme as well as
>> any changes. Looking at how WordPress implements wp_insert_post()
>> and wp_update_post(), I can say that that is far better than any
>> design I've seen and have so far implemented. Actually, I have
>> sinced strived to implement my APIs like wp_insert_post() and
>> wp_update_post() in that inserting into tables uses CRUD or BREAD
>> (I'm not so sure ORM or the others are any better or worse, just
>> solves a different problem or the same problem differently).
>> So the underlying DB implementation uses CRUD or BREAD or whatever
>> pattern or fad everyone is using this year, but the API above it is
>> not. So I suppose what I mean to say is that I'm not in favor of
>> forcing the user of the API to use CRUD, but okay for the developer
>> to do so in order to Get Shit Done and build an API that the user
>> can understand quickly and easily.
>> I think at the end of the day, if the choice is Getting Shit Done
>> or Getting Shit Done right, which also means never, then I'll
>> choose to have something rather than nothing. Which is why I keep
>> having to kick myself in an attempt to not say anything stupid and
>> take away from something that in all regards is actually pretty
>> kick ass.
>> Jacob Santos
>> On Sun, 26 Jul 2009 21:41:30 -0500 (CDT)
>> Mike Schinkel <mikeschinkel at newclarity.net> wrote:
>>> I'm curious; if CRUD is bad, what is good?
>>> -Mike Schinkel
>>> Custom Wordpress Plugins
>>> ----- Original Message -----
>>> From: "Jacob Santos" <wordpress at santosj.name>
>>> To: wp-hackers at lists.automattic.com
>>> Sent: Sunday, July 26, 2009 10:24:20 PM GMT -05:00 US/Canada Eastern
>>> Subject: Re: [wp-hackers] Meta tables: Take 5
>>> Well, I think it is fine, except for object_id doesn't really have
>>> an explanation. Why not $id, instead? The problem is that it
>>> doesn't explain what the object part is, so it can be anything. It
>>> is the ID of the type you are looking for, so post, comment,
>>> category, etc. Why not just name it ID and leave out the question
>>> of what 'object' means. People understand what ID means.
>>> I'm not trying to argue against CRUD, I just wish another pattern
>>> or architecture was choosen for WordPress. CRUD is very simple and
>>> quick to implement. I just shudder every time I see it within
>>> WordPress and within my own code (papa doesn't like spending
>>> forever on "proper" design). Therefore, I'm trying to not argue
>>> CRUD in a wierd way, but still say it sucks and I very much hate it.
>>> Jacob Santos
>>> On Mon, 27 Jul 2009 03:17:30 +0300
>>> scribu <scribu at gmail.com> wrote:
>>>> On Mon, Jul 27, 2009 at 12:21 AM, Jacob Santos <wordpress at santosj.name
>>>>> CRUD in procedural form. Alas, it seems flawed somehow. The
>>>>> look, the feel;
>>>>> The wonder about how to make it better. Is there such a solution?
>>>>> It seems a pity to look at something so beautiful in its
>>>>> simplicity and
>>>>> then ask why? What purpose is there to mock something that
>>>>> should be so
>>>>> clerished and loved and yet not provide another?
>>>>> Not that objects are any better, just better organized. A shame
>>>>> I do cry every time I see CRUD.
>>>>> Good work nevertheless. I hope you choose to name the parameters
>>>>> There is a concept called, "Self-documenting Code" that is just
>>>>> awesome in its beauty and soft skin.
>>>>> Jacob Santos
>>>> Thanks for the comment - very poetic, but not really helpful.
>>>> Don't know how I could rename the parameters to be more self-
>>>> than they already are. Metaphors maybe? :)
>>>> wp-hackers mailing list
>>>> wp-hackers at lists.automattic.com
>>> Jacob Santos <wordpress at santosj.name>
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>> Jacob Santos <wordpress at santosj.name>
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers