Is there a super() in 2009.1?

1 view
Skip to first unread message

Dawn Wolthuis

unread,
Oct 17, 2009, 10:26:55 PM10/17/09
to intersystems-mv
I'm writing up some notes and wanted to check to see if it is still
the case that there is no super() in mvbasic methods in a class.
Anyone know? thanks. --dawn

--
Dawn M. Wolthuis

Take and give some delight today

Ed Clark

unread,
Oct 18, 2009, 12:53:55 PM10/18/09
to InterSy...@googlegroups.com
afaik, there is no equivalent for ##super() in mvbasic.
##super in object script is essentially a macro. For example, if you
have a parent class th.parent and a child class th.child with a method
doit, the line:
d ##super()
in the child class actually expands to
d ##class(th.parent)$this.doit()
in the int routine that the class compiles to. The class compiler
resolves the parent class name at compile time and lays down a cast.
Unfortunately, afaik, there is also no syntax in mvbasic to accomplish
a cast either. So if you want to call the parent method, you need to
include an objectscript helper method to do so.

Dawn Wolthuis

unread,
Oct 18, 2009, 1:23:51 PM10/18/09
to InterSy...@googlegroups.com
What we are doing with methods that are required for various
functionality in Zen is to have them call a method and have each
subclass call that method if they need to add functionality there. For
example, in superclass we have

ClassMethod %OnPreHTTP() As %Boolean [ ServerOnly = 1 ]
{
@ME->OnPreHTTPSupername()
return 1
}

ClassMethod OnPreHTTPSupername()
{
* do stuff here
}

Then in subclass if we have an %OnPreHTTP(), it first has
@ME->OnPreHTTPSupername()

Then has its own logic. This seems like a kludge while awaiting a
super() in mvbasic, but it sounds like this might be the best way to
do this now and for the future. This is an acceptable, if kludgy,
workaround, I guess. Thanks. --dawn

Ed Clark

unread,
Oct 18, 2009, 1:51:11 PM10/18/09
to InterSy...@googlegroups.com
That should work. What I imagined was somewhat the same, but with no
additional duplicate methods in the parent class, and an extra method
in the child:

ClassMethod OnPreHTTP() As %Boolean [ServerOnly=1] {
@me->OnPreHTTPParent() ;* in your scenario this method is in the
parent class, and you need to know the parent name, but in mine it is
in this child class
}

ClassMethod OnPreHTTPParent() As %Boolean [ServerOnly=1,
language=cache] {
do ##super()
}

Your plan has the advantage of limiting the number of extra methods--
the helpers are all in the parent class with none in the children. But
when you create each of the children, you need to know the parent's
name (which admitedly isn't too likely to change). In my scenario, you
don't need to know the parent classes name--OnPreHTTPParent is the
literal method name. ##super in a cos method does the work of
resolving the parent's name.
In my scenario, if there ever is a ##super equivalent added to
mvbasic, you only need to change the child class. In your scenario,
you need to change both the parent and child (to get rid of the extra
method in the parent, and to call the base method in the child). But I
don't know that either really has a big advantage over the other.

Dawn Wolthuis

unread,
Oct 18, 2009, 2:01:12 PM10/18/09
to InterSy...@googlegroups.com
Yes, your scenario has some pros and cons, as does mine. Mine has the
advantage of keeping the languages of the page class to mvbasic and
javascript, without adding COS methods in there too. Thanks. --dawn
Reply all
Reply to author
Forward
0 new messages