Great info. I'm on the waiting list for Codespaces
- Log in to post comments
Great info. I'm on the waiting list for Codespaces
Hi Benjamin, does 2020.4 include Ebedded Python ?
You only need Try-Catch when you expect that something might go wrong and can't handle it upfront.
For regular error-handling, something that you anticipate never happens, the $ZTrap-ErrorHandler is much more elegant. It doesn't introduce extra stack-levels and identation.
%Status is an elegant way of letting the caller know something went wrong and leave it to it's discretion to do with it whatever is appropriate, the callee should have done anything to handle the 'error' properly, logging, recovery, whatever. It's a matter of seperation of concerns.
Method (or Function) overloading isn't necessarily an OOP-thing.
Many programming languages only allow a constructor to have the name of the class itself.
In COS you can have many constructors with different names and signatures, so overloading isn't really needed.
About RESTfull...
/search isn't really RESTfull, REST works on Resources (e.g. /persons or /orders)
To query Resources you use GET (with parameters)
But this is all very 'religious'. To use POST for a complex query is IMO defendable, but then I would do that on a Resource.
You should have a look at the OData (Oasis) specification: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=odata
Anyone who is doubting multiple-inheritance is insane.
Although calling this kind of inheritance 'mixin-classes' helps I've noticed, mixing in additional features.
Robert
You're right it works, but ... you loose the method signature/contract.
With a Method such as:
Method(Name as %String, Address as Address, Age as %Integer)
The compiler can enforce the right named arguments:
Do Method(Age=32) -> OK
Do Method(Car="Maserati") -> not OK (except for the car of course ;-))
The only real solution is support of named arguments (like Python)
They are on my ISC wish-list for many years ;-)
To incorporate in COS-native is a challenge, but in Methods it shouldn't be so hard.
Set sc=##class(%RoutineMgr).GetWebServerPort(.Port,.Server,.URLPrefix,.URL)
Shouldn't that be:
Set MyObj.JSON={}.%FromJSON(JSONString)
In a true OO-fashion, you should use private properties for that. Available anywhere within your (instantiated) class, but not for the 'outside' world.
It seems that this function hasn't been updated to cater for quoted property names.
Property "Long_Address" As %String;
.. is a valid property name, but $ZName("""Long_Address""",6) returns 0
It would help if ISC would provide a clear roadmap for their 'Editor/IDE' policy, being Studio, Atelier or (preferably) something else.
Studio was 'replaced' by Atelier, Atelier is 'end of life' and now Iris Studio ?
Hi John,
Will one of you be in Antwerp next month to present/demonstrate this ?
Six quotes :-O
Trial and error or is there any logic behind that ?
The Write obj.%ToJSON() writes to the TCP stream of the HTTP Response, the headers are written before the body.
You' have to call the ReportHttpStatusCode first (which is nothing more then: Set %response.Status=HttpStatus) and then write the body.
I don't think this kind of marketing material should be on IDC.
My two cents.
More standard is just to call a function: onsubmit='function(...);' without the 'return'
It seems just to work the other way around then I anticipated, I haven't had any time to actually try it
In the OnSubmit you use a 'Return function' (which is unusual). Your function returns nothing, a 'false' by default, so I suspect the complete submit is cancelled because of the 'return false'. But that's only a guess.
Can you please provide up-to-date Release Notes ?
In what way you where involved in the choice for Eclipse I don't know.
But in my (not so) HO, that was a very bad choice. Eclipse is a jack-of-all-trades that serves no-one.
If ISC would have made a choice for Git as a SC a long time ago (conflicting probably with long-time parties such as GJS) , Studio could have been vialble. Only on Windows. But I think the developer wars on Win/Lin/Mac are long time settled on VM's and containers.
Building on Studio further, opening up API's (Atelier), supporting Language Server Protocol , ISC could have been less dependent on others.
In the first place I'll have to say that I never understood the choice for Eclipse as the base for an ISC editor/ide.
So I'm not that sad, for this decision.
But what will we get then ?
I think ISC is big enough to have their own IDE (do we need an IDE ?)
It could be home-grown (a little bit too late) or Atom based, which is a editor not an IDE.
If ISC abandons BPL (which I think is really a very bad thing), it would make a transition much easier.
What you probably need is some kind of OnCompile callback in which you would be able to change the actual class definition based on meta data.
Adding methods and properties.
This is something I've asking for since the incarnation of Cache in 1997.
(still not herding sheep in Tuscany ;-))
How would you want to address a string with the value of "true" if there would be automatic translation to 1 ?
Ah, there's my non-native English: I 'translated' that as 'opposite' in the sense of exclusive, sorry
They're not orthogonal.
Consider a Person class:
Person
Method AmISmarterThenTheRest() {
Set AvgIQ=..GetIQ(..HairColor)
}
ClassMethod GetIQ(HairColor) [Private] {
; determine the average IQ by HairColor
}
The GetIQ method is obviously a class method, but you might not want to expose it to the outside world.
There's where one needs (wants) a private class method
But what will this do with Object storage/access or (direct) global storage/access ? Is this data SQL-only ?
You cannot know at forehand.
Superclasses can define their own PropertyClass and they reflect in the subclasses.
For instance if your class inherits from %XML.Adapter every property of that class gets extra parameters such as XMLNAME and XMLPROJECTION.
As I recall Character-type streams always translate to Unicode.
You could try a Binary stream, which does not do any translation
HTH