Generating object graphs, exposing method types, etc.

[Will]

Hello,
I found F-Script a few days ago, and I must say it's pretty
impressive. I've since been poking around apps with it and figuring
out it's capabilities. :)

I really want it to be my new high-power dev tool. I would like to use
it for application state analysis, similar to the Developer Tools'
Instruments, e.g. to sample a large number of objects (preferably all
of them without having to compile in special profiling code) and dump
the data to be further analyzed. The other use I would like is to be
able to expose arbitrary class interfaces (method argument/return
types, really), to ease the use of private frameworks with my
development tools. Disclaimer: I'm aware of the fluctuating nature of
private frameworks, and my purpose is not to make software based on
them for general public consumption.

It seems F-Script can do both of these tasks, but only interactively.
I delved into its workings a bit and came to the conclusion that type
introspection is inextricably tied to the executor (a method must be
executed before type information is exposed), and objects are only
accessible via class methods which are only browsable via the gui (via
the interpreter you cannot get a list of all classes, let alone all
objects in memory). I could very well be wrong, though. I hope I am,
anyway. :)

I fiddled around a bit with the F-Script framework source and I've
worked out hacks for the things I want to do (although the type
introspection hack is a doozy). Is there a good way to accomplish
these things without ugly hacks? I would really appreciate some expert
knowledge.

Will

[Philippe Mougin]

Hello Will,

Thanks for this description of your anticipated usage of F-Script.
Sounds quite nice !
As you noted, there are functionalities that are not immediately
available from within the F-Script language. The general way to expose
such functionalities to F-Script without ugly hacks is simply to
implement, in Objective-C, the functionalities you need, wrap them
inside objects and package that as bundles (or as frameworks) that you
can then load in F-Script when needed (see the doc for loading
options).
For example, getting the list of all classes is easy to do in
Objective-C. You just need to wrap that functionality in a class that
can then be loaded by F-Script and used. For instance, this utility
class could have a method named "allClasses" that would return an
NSArray of classes objects.

Philippe

[Will]

Hi Philippe,
Thanks for the quick response. I have spent some time looking at the
internals of F-Script, and I don't really see a clean way of
implementing those in Objective-C. As you said, the allClasses
functionality is easy, simply a matter of wrapping the appropriate
objc_ calls. However, the others are a different matter.

I know of no such queries that expose object type information, and yet
F-Script somehow does exactly that upon executing a method-- if the
incorrect type is given, the executor's error message contains
information stating the correct type. Even more amazingly, when given
the correct object but incorrect content (say an NSArray with
NSStrings when it was supposed to be an NSArray with NSDictionaries),
it displays errors about the incorrect usage of the contained data due
to a call from within a foreign method. I imagine this is accomplished
through the use of categories, however I haven't completely figured
out the flow of F-Script yet, and where the type information is first
exposed.

I'm pretty certain most of the functionality I'm trying to get must be
implemented in a category overriding NSObject methods (especially
tracking all active objects), but it warrants more investigation. The
progress is somewhat slow, unfortunately.

Will

[Philippe Mougin]

Hi Will,

F-Script uses two approaches to do parameter validation at run time.

First, it makes use of information returned by the method
"methodSignatureForSelector:" (see
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/methodSignatureForSelector:).
This provides information about expected type of parameters (e.g.,
int, double, object, etc...). Note, however, that it doesn't return
precise information about the expected class of a given object
parameter (i.e., it doesn't tell you if the parameter is expected to
be an NSString or an NSArray, just that it must be an object. This is
somewhat understandable as Objective-C allows for duck typing). A way
to get at more precise typing information is to use the BridgeSupport
files (see http://developer.apple.com/mac/library/DOCUMENTATION/Darwin/Reference/ManPages/man5/BridgeSupport.5.html).
F-Script doesn't use BridgeSupport files for that, though.

Second, in addition to the generic validation system based on
"methodSignatureForSelector:" as described above, methods provided by
F-Script do some additional parameter validation themselves. This
validation code is programmed by hand and hardwired into methods. For
example, the method "ifTrue:", provided by FSBoolean objects, starts
by looking at the actual class of the object passed as argument and
generate an error if it is not an instance of the FSBlock class.

Philippe