Docs/examples are scant and searching GitHub code I see a few real-world uses of either ObservedRealmObject or StateRealmObject with apparently similar usage and utility.
I'm also surprised that neither can take an optional. Instantiating a default throwaway object isn't great either because RealmSwift models now allow required/non-optional properties. (Does this also mean that it's OK to also use #State for Realm objects when wanting an optional?)
For specific use case to reference, I'm trying to use one of these to store a selection object.
Related
The goal is to have a table where the rows are different types, and each is a 'component.' So imagine the LandmarkRow from the Apple Tutorial, but instead of Landmarks, we were also going to show Accommodations as well. I want to make each its own component, that part is easy.
The part that is more challenging is how I get the view from each, if they are in a collection. What would be ideal is if they both implement a protocol, and then I can have them in a collection of types that includes that protocol and then just call the commmon method, e.g. buildView. The problem is is that opaque types seems to break inheritance. If I make a build() -> some View method in the base, providing an implementation in the derived classes is not seen as an override. So I don't get the derived. Instead, for now, I am just doing if item is Landmark for each type in the body of the table view.
Just to be super clear, I don't want a switch or a block of if statements, this is OO 101: we should be able to derive a new type that implements the protocol then add that type into the collection that the table is composed of.
We did find that we could force cast the view to the protocol and then call the method, that works. Has the advantage of not having to edit a switch or if block each time a new view is added, but still unnecessary/incorrect.
Since you need them all to return the same type (a type that conforms to View), you'll probably want to have them all return AnyView.
Turns out Apple does provide a solution to this, though not in the sample, but in the session 'SwiftUI on All Devices.' Around 26 minutes in they discuss providing 2 different LandmarkRow implementations, but they do not use inheritance. They use generics and a lambda. There is no code in the resources for this but you can see it all in the session.
How do I create an object in python from a feature class in a geodatabase? I would think the following code would create a featureclass object?
featureclassobject = "C:/path/to/my/featureclass"
But this creates a string object, right? So I am not able to pass this object into an arcpy function later on.
You are correct that it creates a string object. However, whether it will work with a particular ArcPy function depends on the function -- in most cases, the tool simply needs to know the path to the function as a string (which the featureclassobject is).
The help pages are slightly unhelpful in this regard. Buffer, for example, says that input parameter in_features needs to be data type "Feature Layer" -- however, what it really expects is a string that describes where the feature layer can be found.
One significant exception to this is geometry objects:
In many geoprocessing workflows, you may need to run a specific operation using coordinate and geometry information but don't necessarily want to go through the process of creating a new (temporary) feature class, populating the feature class with cursors, using the feature class, then deleting the temporary feature class. Geometry objects can be used instead for both input and output to make geoprocessing easier.
But if you've already got a feature class (or shapefile) on disk, that's much simpler than creating an in-memory geometry object to work with.
Following my reading of the article Programmers Are People Too by Ken Arnold, I have been trying to implement the idea of progressive disclosure in a minimal C++ API, to understand how it could be done at a larger scale.
Progressive disclosure refers to the idea of "splitting" an API into categories that will be disclosed to the user of an API only upon request. For example, an API can be split into two categories: a base category what is (accessible to the user by default) for methods which are often needed and easy to use and a extended category for expert level services.
I have found only one example on the web of such an implementation: the db4o library (in Java), but I do not really understand their strategy. For example, if we take a look at ObjectServer, it is declared as an interface, just like its extended class ExtObjectServer. Then an implementing ObjectServerImpl class, inheriting from both these interfaces is defined and all methods from both interfaces are implemented there.
This supposedly allows code such as:
public void test() throws IOException {
final String user = "hohohi";
final String password = "hohoho";
ObjectServer server = clientServerFixture().server();
server.grantAccess(user, password);
ObjectContainer con = openClient(user, password);
Assert.isNotNull(con);
con.close();
server.ext().revokeAccess(user); // How does this limit the scope to
// expert level methods only since it
// inherits from ObjectServer?
// ...
});
My knowledge of Java is not that good, but it seems my misunderstanding of how this work is at an higher level.
Thanks for your help!
Java and C++ are both statically typed, so what you can do with an object depends not so much on its actual dynamic type, but on the type through which you're accessing it.
In the example you've shown, you'll notice that the variable server is of type ObjectServer. This means that when going through server, you can only access ObjectServer methods. Even if the object happens to be of a type which has other methods (which is the case in your case and its ObjectServerImpl type), you have no way of directly accessing methods other than ObjectServer ones.
To access other methods, you need to get hold of the object through different type. This could be done with a cast, or with an explicit accessor such as your ext(). a.ext() returns a, but as a different type (ExtObjectServer), giving you access to different methods of a.
Your question also asks how is server.ext() limited to expert methods when ExtObjectServer extends ObjectServer. The answer is: it is not, but that is correct. It should not be limited like this. The goal is not to provide only the expert functions. If that was the case, then client code which needs to use both normal and expert functions would need to take two references to the object, just differently typed. There's no advantage to be gained from this.
The goal of progressive disclosure is to hide the expert stuff until it's explicitly requested. Once you ask for it, you've already seen the basic stuff, so why hide it from you?
Hoping someone can provide an explain-like-I’m-five elucidation of the difference between the following types of functions within Famo.us, and when it’s appropriate to use them:
sampleFunction() {}
_sampleFunction() {}
SampleView.prototype.sampleFunction() {}
.bind and .call are also thrown around a lot…I understand them vaguely but not as concretely as I’d like. That might be a different question, but please feel free to use them in your explanation!
Apologies for the vagueness...wish there was more regarding this in famo.us university.
None of what you're looking at is syntax specific to Famo.us. It's actually common, if intermediate level, VanillaJS.
The _ is simply a coding convention to denote that a specific function should belong to the parent scope (ie a member/private function, whatever you prefer to call it). Javascript doesn't really have support for encapsulation - the act of blocking other classes and objects from accessing another class's functions and variables. While it is possible, it's quite cumbersome and hacky.
You'll see that Famo.us uses the underscore convention to denote that a function is a member of the class using it. Some of these functions are actually just aliases to the actual Javascript native function, for example ._add actually just call's Javascript's .add method. Of course, ._add could be updated in the future on Famo.us's end to do more in the future if that's required. You really wouldn't want to try and write over the native Javascript add. That's super bad.
The other upshot is that you can document that class and say that you can and should use the _add method for a specific purpose/scenario. You'll see that in the API docs.
Understanding prototype is a core part of what it means to be a Javascript Programmer, after all, it is a prototype driven language. MDN has a much better explanation than anything I can offer here but it's basically at the core of your classes.
If you want to extend off of an existing class (say, create your own View or Surface type) you would extend it's prototype. Check out Famous Starter Kit's App examples and see how many of them create an "AppView" class, which takes the prototype of the core View, copies it for itself, and then adds it's own functions, thus extending View without ruining the original copy.
I am attempting to make my code as testable as possible, which means using dependency injection correctly.
I have read that it's okay to use new() to instantiate an object, if that object meets certain criteria. Notably - it should not accept a "non newable" in its constructor.
For example, I should be able to go
new Form('signup');
because there is no way that my DI container would know how to create the "signup" form ahead of time.
I can make this work most of the time, but now I'd like the Form to be able to validate itself, using a third party validator, like:
$form->validate()->isValid();
...which means that I would have to pass in a validator service.
I'd really prefer to have the validator included already because most of the time the form will need to be validated, and I'd have to go through the extra work to set the validator on my own otherwise.
Is it okay, in this instance to do:
new Form(Validator $validator,$name);
I'd say that any value or object which an object requires in order to be in a valid state is one of that object's dependencies; in your example that would entirely validly include the form's name. I don't think the type of a dependency can be used to say whether it should be injected or not - Martin Fowler in this article for instance shows objects having strings injected into them, and DI containers can usually be configured to supply string values.
With this in mind, injecting the validator and the string is fine and entirely correct in my opinion.