Thread Subject:

Builtin function name resolution...

Hypothetical, mostly...well, not _entirely_ :)

_IF_ (the proverbial "big if") one were to wish to extend a builtin
function to add some functionality or to match syntax w/ a later rev,
the easiest implementation would often be to add a function definition
in the appropriate @class subdirectory of the same name that
preprocesses the input and then passes that to the builtin method and
then (possibly) postprocesses that output before returning.

OK, the question is, how does one make the call to the builtin function
in the overloading version in order to avoid recursion? Or, is it even
possible?

--

dpb <none@non.net> wrote in message <jt9rr1$dih$1@speranza.aioe.org>...
> Hypothetical, mostly...well, not _entirely_ :)
>
> _IF_ (the proverbial "big if") one were to wish to extend a builtin
> function to add some functionality or to match syntax w/ a later rev,
> the easiest implementation would often be to add a function definition
> in the appropriate @class subdirectory of the same name that
> preprocesses the input and then passes that to the builtin method and
> then (possibly) postprocesses that output before returning.
>
> OK, the question is, how does one make the call to the builtin function
> in the overloading version in order to avoid recursion? Or, is it even
> possible?
>

Surprise there _is_ a function called ... builtin() right on for that purpose.

Bruno

dpb <none@non.net> wrote in message <jt9rr1$dih$1@speranza.aioe.org>...
> postprocesses that output before returning.
>
> OK, the question is, how does one make the call to the builtin function
> in the overloading version in order to avoid recursion? Or, is it even
> possible?
=============

As Bruno says, it's possible using BUILTIN, but it's a bad idea. Remember that a lot of common MATLAB functions are just ordinary mfiles which might call the function you're trying to extend and may not be prepared for the new functionality that you're adding to it. It's better/safer just to use a different name for the function.

On 7/7/2012 1:02 PM, Matt J wrote:
> dpb <none@non.net> wrote in message <jt9rr1$dih$1@speranza.aioe.org>...
>> postprocesses that output before returning.
>>
>> OK, the question is, how does one make the call to the builtin
>> function in the overloading version in order to avoid recursion? Or,
>> is it even possible?
> =============
>
> As Bruno says, it's possible using BUILTIN, but it's a bad idea.
> Remember that a lot of common MATLAB functions are just ordinary mfiles
> which might call the function you're trying to extend and may not be
> prepared for the new functionality that you're adding to it. It's
> better/safer just to use a different name for the function.

Hmmm...I somehow missed builtin(); it was never referenced in the
linkage or verbiage in sections on name resolution in my version and I'd
not tried anything like this before...

And, yes, I understand the caveats--which is why I did say it was
(mostly) theoretical but I think I will do a little bit of
experimentation to add some of the simpler enhancements to certain
functions that have been done since my release. If I'm reasonably
careful w/ what I choose to play with and how I deal with the
inputs/outputs, I should be able to retain compatibility.

My intent is not to add anything that isn't consistent with newer syntax
and to ensure that for existing functions the same is expected/returned
as current. If I can't achieve that goal on a given function in its
entirety, I would hope I could at least trap the conditions and abort to
the builtin first.

But, since I'm retired and have no immediate prospects for any clients
to return from the (growing ever more) distant past, it's not like I've
any critical need that I can't just back out and revert to the present
version either until I can fix a problem or devise a solution...

Thanks (and Bruno, too...)...

--

On 7/7/2012 1:02 PM, Matt J wrote:
...

> As Bruno says, it's possible using BUILTIN, but it's a bad idea.
...

It works!!!! :) At least so far...

My first exercise was to build a wrapper for find() that includes the
'K' and 'first'|'last' optional inputs that this rev doesn't support. I
had built a function some time ago called MYFIND() but most of the time
I forget even having done so or when doing some sample code just use
FIND automatically that it really hadn't done me any good to have done so.

The other thread just earlier than this got me thinking about it again
and deciding I really, really, really wanted my version to have the
facility.

So far it hasn't broken anything else (knock on wood :) )...

I have just a few others of the more common that I would like to do as
well. I don't mind fouling up the installation directories w/ my
modifications; I'm never going to upgrade unless the client w/ really
big bucks shows up and if that exceedingly unlikely event were to happen
it'll be a whole new system anyway...

I keep backups and the worst is I reinstall and copy stuff back from the
version control system files on an incremental basis. There's no
critical data associated w/ Matlab here any longer--that's just too far
in the past.

I've spent quite a lot of time in the office playing the last couple of
weeks owing to the extreme heat and drought conditions so there's no
farming to be done and it's too hot to do anything that just doesn't
_have_ to be done so I'm playing... :)

--

dpb <none@non.net> wrote in message <jta1kh$r4g$1@speranza.aioe.org>...
>
>
> It works!!!! :) At least so far...
>
> My first exercise was to build a wrapper for find() that includes the
> 'K' and 'first'|'last' optional inputs that this rev doesn't support. I
> had built a function some time ago called MYFIND() but most of the time
> I forget even having done so or when doing some sample code just use
> FIND automatically that it really hadn't done me any good to have done so.
>
> The other thread just earlier than this got me thinking about it again
> and deciding I really, really, really wanted my version to have the
> facility.
>
> So far it hasn't broken anything else (knock on wood :) )...
>
> I have just a few others of the more common that I would like to do as
> well. I don't mind fouling up the installation directories w/ my
> modifications; I'm never going to upgrade unless the client w/ really
> big bucks shows up and if that exceedingly unlikely event were to happen
> it'll be a whole new system anyway...
>
> I keep backups and the worst is I reinstall and copy stuff back from the
> version control system files on an incremental basis. There's no
> critical data associated w/ Matlab here any longer--that's just too far
> in the past.
>
> I've spent quite a lot of time in the office playing the last couple of
> weeks owing to the extreme heat and drought conditions so there's no
> farming to be done and it's too hot to do anything that just doesn't
> _have_ to be done so I'm playing... :)
==============

Well, that justifies doing it as much as one could hope to.

My fear wouldn't be things crashing, though. It would be the errors that are less noticeable - incorrect output of usual MATLAB routines that are hard to detect. Even when doing toy projects, it can be frustrating to see output that doesn't jive with your intuition and then to have to wonder whether your own functions or Mathworks functions could be responsible. When doing this, I would surely want to do thorough testing or be sure that I'm defining a completely new calling syntax for the function (under the MATLAB version I'm running).

On 7/7/2012 3:03 PM, Matt J wrote:
> dpb <none@non.net> wrote in message <jta1kh$r4g$1@speranza.aioe.org>...
...
>> My first exercise was to build a wrapper for find() that includes the
>> 'K' and 'first'|'last' optional inputs that this rev doesn't support.
...
>> So far it hasn't broken anything else (knock on wood :) )...
...

> Well, that justifies doing it as much as one could hope to.
> My fear wouldn't be things crashing, though. It would be the errors that
> are less noticeable - incorrect output of usual MATLAB routines that are
> hard to detect. ...
> ... When doing this, I would surely want to do thorough testing
> or be sure that I'm defining a completely new calling syntax for the
> function (under the MATLAB version I'm running).

Indeed, 'breaking' includes bad output, too. And, if it did silently
return a bum output from a core function that makes debugging more
difficult if one has aliased the default either builtin or TMW-supplied
m-files. That is why I am always sure to keep both the original
unmodified as well as using a VCS for updates to be able to revert
easily if I do ever run into such a problem.

I had tested the wrapper function around FIND pretty thoroughly before
and it is one in which the added syntax is really quite simple to add as
it is essentially just limiting the output to a subset of the full
output when using the K optional argument and picking whether that goes
from the front or the rear for the 'first'|'last' argument.

Some others w/ more extensive changes could be far more challenging but
I doubt I'll get _too_ carried away given it's just entertainment! :)

The most exotic I've done was to add operator support via mex-files for
class SINGLE but I did that years and years ago when was still working
and this was, in fact, the latest release.

The next most was a piece I seem to have lost in the retirement move
from the job and back to the farm--that was the implementation of a poor
man's Fortran FORMAT output formatting facility--I can't seem to find
that code on any of my machines--somehow I guess I never got a copy off
a company machine to the house. :(

I had promised a copy of it to Steven L in a conversation when I brought
up my obligatory complaint about C/Matlab formatting to support an
enhancement request but haven't been able to do so... :( It's now been
so long I've really forgotten precisely how I did it even altho it
mostly just passed FORMAT-like strings to a Fortran mex, obviously.
When I first retired from employment and went on own, the work was doing
wasn't using Matlab at all so it was several years before I discovered I
didn't have it and too late to have any hope of retrieving anything.

Anyway, that's _far_ more than anyone else is possibly interested
in...I'll go away. :)

--

On 7/7/2012 3:03 PM, Matt J wrote:
> dpb <none@non.net> wrote in message <jta1kh$r4g$1@speranza.aioe.org>...
...
>> It works!!!! :) At least so far...
>>
>> My first exercise was to build a wrapper for find() that includes the
>> 'K' and 'first'|'last' optional inputs ...
...
> Well, that justifies doing it as much as one could hope to.
...

Ok, I now see one thing that doesn't _quite_ work as I'd like...

I added descriptions of the additional syntax to the base m-file but
even after a restart it still shows the original--is the actual text of
the builtin functions help actually in the code itself and not using the
m-file? I had always thought that's why they were there--seemed no
reason for them to even be distributed otherwise.

So, is there no way to get the enhanced help w/o the specific naming of
the overloaded function in the command? Or am I overlooking something
obvious here?

--

dpb <none@non.net> wrote in message <jta966$cnk$1@speranza.aioe.org>...
> On 7/7/2012 3:03 PM, Matt J wrote:
>
> So, is there no way to get the enhanced help w/o the specific naming of
> the overloaded function in the command? Or am I overlooking something
> obvious here?
===========

Does your find.m precede the native find.m on the MATLAB path?
Type "which -all find.m" to check.

On 7/7/2012 5:12 PM, Matt J wrote:
> dpb <none@non.net> wrote in message <jta966$cnk$1@speranza.aioe.org>...
>> On 7/7/2012 3:03 PM, Matt J wrote:
>>
>> So, is there no way to get the enhanced help w/o the specific naming
>> of the overloaded function in the command? Or am I overlooking
>> something obvious here?
> ===========
>
> Does your find.m precede the native find.m on the MATLAB path?
> Type "which -all find.m" to check.

Oh, DUH! <slaps head> Forgot I had temporarily put a copy in my working
directory for precisely that reason...

I was sure I had made some corrections/additions to the help files over
the years but w/ the replacing the builtin I let that confound me into
thinking maybe something really deep was going on...

Thanks...all's well now.

--