Re: [SMARTY-DEV] Re: object support

Monte wrote:

As do I, and we made a valiant effort to come up with a feasible way to support objects without a new syntax. Every idea tried had too many shortcomings. If you have one, speak up. It's not released yet. I'm all ears :-)

First of all, I think we have to recognize that not all shops have the designer/programmer distinction. Plenty of pure-programmer outfits exist, which welcome freedom over "consistency". Here's two examples of perfectly valid object constructs that represent the kind of behavior I'm interested in letting the templates use: class Person {

    var $firstName, $lastName;
    function getFullName() {
	    return $this->lastName . ", " . $this->lastName;
    }

} Having access to the getFullName() is not about tampering with business data, but about giving a more appropriate view on the object data. Yes, I _could_ use the overload structure, but that seems much more hack'ish, and pollutes the object with work-around code that isn't needed on the PHP-side of things. Another 4.3.0+ use is this: {$people->getPerson("Monte")->getAgeOnDate("2003-01-22")} Again, I think this is a perfectly valid and non-hack'ish way of doing things that wouldn't be possible with the consistent Smarty approach. "But you could just assign Monte in advance?", that kinda works with just one Monte, but certainly not with an array of people objects. And it just seems silly that I have to pick my OO graph apart to assign bits and pieces to the template when I could just assign the whole thing. Like, $smarty->assign("footballTeam", new FootballTeam()); Coach: {$footballTeam->getCoach()->getFullName} Number of players: {$footballTeam->getPlayerCount()} {foreach from=$footballTeam->getPlayers() item=player}

    Name: {$player->getFullName()}
    Last Match: {$player->getLastMatch()->getResult()}

{/foreach} Assigning all the stuff I would need to build the above is a huge inconvenience and would feel incredibly unnecessary. I do, however, perfectly understand the argument that designers shouldn't be burdened with knowledge about OOP, but why would this syntax require that? If you're working with designers that shouldn't be exposed to OOP, you just go about business the old way, and assign things in bits and pieces. Nobody would force your hand in using this more advanced syntax if you felt it wasn't right for your audience. Additionally, I'd heartily welcome a designer-friendly syntax, which would give you limited OO facilities as long as the PHP-way and all of its advantages were still available for the pure-programmer outfits to use. -- David Heinemeier Hansson http://www.loudthinking.com/ -- Broadcasting Brain