Re: instanceOf and/or isAssignableFrom operator in freemarker

Daniel Dekany <[email protected]>
Newsgroups gmane.comp.web.freemarker.user
Message-ID <[email protected]>
Thursday, April 23, 2009, 1:24:26 PM, Attila Szegedi wrote:
> On 2009.04.23., at 13:07, Daniel Dekany wrote:
>
>> Actually, Attila, can't BeansWrapper already do that? I don't know...
>
> When the objects are exposed through BeansWrapper, it is indeed  
> possible to access the class of the object using either obj.class or  
> obj.getClass(), so you can call instanceOf and isAssignableFrom on them.
>
> The thing that's not trivially possible is to obtain an arbitrary  
> Class object given its name...

We have the same kind of problem with statics and enums. You have
addressed that with adding something like getStaticModels() and
getEnumModels() to BeansWrapper. I guess the same should be done with
classes in the first iteration of addressing this issue. But...
getStaticModels() and like don't really shine in practice, because
they are hard to get working. Like, grab a Web application framework
that's not home-grew (and hence maybe heavily optimized for FM), and
chances are high that you won't be able to put those models into the
data-model easily. That could be addressed with a *dirty* hack of
adding an FM setting like "initScript" (no guys, we don't have that
yet), since frameworks mostly just expose the Properties (oh, the
horror) based configuring (oh the horror, again) of FM. But... well,
that's quite a complication for the *user* for achieving something
that is just there in most languages. Now, due to the type-system of
FTL (which is *maybe* a right design for a View language, apart from
some glitches in it) I wouldn't recommend it in the very heart of FTL,
but could we possibly, like, just make these things available as
built-in variables, .enums, .classes, .statics? (Some will come with
the security implications, but I think whoever things FTL is more
secure than the Java Language... let's say, can find himself in
trouble quickly). It will be still terribly complicated:

  .classes["com.example.Foo"].isInstance(obj.class)

and you already have language feature that depends on something that
is not part of the language... Yeah, clean language design my a**,
right? Well, right and too bad. Anyway, then we might as well skink
deeper and:

  obj?instanceOf("com.example.Foo")

which will fail if obj is not BeansWrapper-wrapped.

> Attila.
>
>> I guess it should be able to, given it *is* for exposing Java object
>> as-is (OK, with some security restrictions and like, but you get what
>> I mean), and the class is a quite important information for Java
>> classes, given that in the Java world duck-typing and like is at best
>> rare.
>>
>> -- 
>> Best regards,
>> Daniel Dekany

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.