also when the method is for a system class (like number, string ...) I really wonder :(
I have a little macro which uses a private function to do this, and also discovered that there is already a private function which is pretty close. One of my colleagues filed this enhancement PCR: PCR: 765646 Title: need to get methods from a generic function When you say "enumerate" what do you mean? Do you mean that you want to find the names of the classes which have methods for the specified generic function? Also, what do you want this for? Good practical reasons always help influence the likelihood of this being implemented. That said, the implementation is mainly a case of providing a public wrapper or alias for the internal function (it is not named appropriately for a public function), and the documentation effort. Regards, Andrew.
So getmethod() will become public ? What about variable ? Is there a way to request, for instance, that oblist becomes public ?
That's the idea. It's not been committed to yet though - but I can't see any major problems in this case. I think that's fairly unlikely, as it could limit our ability to change low level implementation details. Also, it's questionable as to what you'd use this for (legitimately). Andrew.
I think that's fairly unlikely, as it could limit our ability to change low Getting out of design trouble ? When PDK or integrated simulator misbehaves and the client should not care about this kind of thing but onloy deadlines, is it legitimate to do a listdiff on oblist between before and after initialisation of PDK (or simulator) ? You are competent Andrew. Just illustrate for me where the line is and I will take it as a golden rule.
Well, if reverse engineering someone else's IP which they have protected (or at least obfuscated) by creating an context file is something you think is ethical, then that's up to you... You're relying on an implementation feature of the language, which we ought to be free to change. If we document something like this, it rather limits our options in the future. Mostly the reason for SKILL API functions being public (and documented) are: a) they are useful to customers b) they are supportable Private functions are private for the opposite reasons - often they don't do enough checking, they require internal data structures, and they are part of the low level implementation. Clearly we cannot ensure that all 50,000 odd functions in DFII keep the same argument list and behaviour from release to release, otherwise nothing would ever change. So a reasonable, practical, subset should be public. If there is a need for a public function for something that isn't there right now, we can always ask for one. That said, I often see customers (not so often the customers I deal with in Europe) asking for Cadence to provide a function that can be written in a few lines of code, and often for something that is rather specific to their needs. My objection here is - write your own library functions! I have built up a collection over the years of functions that I reuse over and over again, for things that do generally useful things, but I wouldn't expect Cadence to provide them for me. Sorry, I rather wandered off topic there, but just wanted to say it... Regards, Andrew.
Andrew, If we could not let some steam off, it wouldn t be a proper news feed That is pretty much on-topic, and gives me part of the answer. You have built over the years a library/API for your needs that relies on features that are not garanteed to keep the same shape and flavour. And you know they can be useful to customers, because they ask for such library. As for IP and reverse engineering... I try to keep a no-nonense approach to this. The business of a partner/customer/provider defines what is critical IP and what is not. I am convinced that some companies write SKILL and then obfuscate it not because it is critical IP, but for the opposite reason: it is a side-activity, and they want to spend as little as possible on it. Obfuscation then gives them the ability to hide the dirty laundry, and at the same time limit the risk of user customisation and change requests. But if they are exposed to the consequence of incomplete/faulty code in a PDK in terms of risk for the tape-out, or shown how a missing feature in a custom application affects design productivity, they just give you "carte blanche" for any reverse engineering of what is not their core-business.
Actually my library of functions for doing various higher level things doesn't generally rely on things that are not guaranteed to keep the same shape and flavour. Occasionally I'll write something around a private function as a short-term fix, but for the most part, my code uses public functions. I have library functions that I wrote 10 years or more ago which are still useful, and have not needed any changes in the meantime (sometimes I've enhanced them, but I've not had to change them because Cadence changed things). That's precisely why I was involved (along with our friend John Gianni, and a number of others within Cadence) in a big effort a few years ago to clearly define what was private and what was function, and set rules and checks such that R&D don't delete or change (in an incompatible way) the public API. These rules mean that SKILL code is generally portable to new releases with no change. Of course, occasionally an API is removed (because the underlying tool was end-of-lifed and removed), and occasionally a change _has_ to happen - but these are rare events. SKILL Lint rules, or the "SKILL Advisor" tool in the SKILL Development toolbox should help inform of those changes and the necessary changes needed to customer code. Regards, Andrew.
