How to use String in Alloy?
What kind of function or operators for String are supported in Alloy?
I searched questions here and find String is a keyword in Alloy.
But I cannot find any reference about how to use String in Alloy.
Could you give one? If not, is possible to give a brief about String in Alloy?
You can actually use strings in Alloy, but only as literals to specify constant values (i.e., no string operations are supported, and Alloy does not implement a string solver). That said, the main use of strings is Alloy is to assign constant string literals to some fields for the sole purpose of making the generated instances more readable when visualized. Here is a simple example
sig Person {
name: String,
email: String
}
one sig P1 extends Person {} {
name = "Joe"
email = "joe#email.com"
}
run {
some p: Person | p.name != "Joe"
}
Related
I have been doing an intense - yet basic apparently - study on structs in these last days and one of the things I cannot understand is why one would ever name parameters in an initializer differently from their original name.
I know that is possible, that it is allowed but, in practice, I have always seen shadowing instead.
For example:
struct Person {
var name: String
var age: Int
init(firstName: String, ancientness: Int) {
self.name = firstName
self.age = ancientness
}
}
Apart from the absurd fun one would have in inventing idiotic names, is there a truly practical reason why one would ever do such a thing?
Thank you
The short answer is no. The long answer is when creating a custom structure you don't even have to provide a custom initializer. The struct will provide it for you. Not related to your question but you should always declare your properties as constants. If you need a different value create a new structure with the values updated from the old instance. Just create a "plain" structure:
struct Person {
let name: String
let age: Int
}
This will provide a the default initializer with the following signature:
Person.init(name: String, age: Int)
If you were gonna provide yourself the same initializer for that structure it would be written as:
init(name: String, age: Int) {
self.name = name
self.age = age
}
the final thoughts
There is no reason to do such thing. You should keep your initializers names matching the name of the properties that they will be assigned to. The only "advantage" of choosing a different name is not having to explicitly call self inside the initializer.
In your example it would suffice
init(firstName: String, ancientness: Int) {
name = firstName
age = ancientness
}
but not on mine
init(name: String, age: Int) {
name = name // Cannot assign to value: 'name' is a 'let' constant
age = age // Cannot assign to value: 'name' is a 'let' constant
}
A Truly practical reason?
The only one I can see is dropping the self which can already be done 99% of the time already when coding in Swift. I actually like a lot to use the shadowing whenever it is possible in all of my answers. You can see it at this post Swift Array instance method drop(at: Int) where a local var indexshadowing the collection method index<T: Comparable>(_ T, offsetBy: T, limitedBy: T).
Or at this post Swift: second occurrence with indexOf a classic shadowing example
var startIndex = self.startIndex
Where you can refer to startIndex local method variable or the collection's instance property adding the self prefix self.startIndex.
I have a grammar that looks like
A:
...
B:
...
I want to be able to give each element of type B some serial ID. So every time that the grammar creates a B object, it gets a (unique) new ID as a field.
I tried to do something like:
B:
myID=Tracer.getID()
...
where:
class Tracer {
static int ID=0;
static int getID() { return ID++;}
But I can't call external java class from the grammar.
It would be better if it's solvable without touching the src-gen files.
Thanks.
Are you aware that in textual models, there is no such thing as object identity? I.e. you fundamentally can't say that any two objects in different ASTs are identical. You can only establish an interpretation of equivalence using diff algorithms.
That aside, if you only need a temporary identity, what about using Object.hashCode()?
I have to use Alloy in a Requirements Analysis and Specification Document for a university project. I started with the easy stuff, only signatures and no facts. These are the signatures I use:
abstract sig Date{
year: one Int,
month: one Int,
day: one Int
}
abstract sig Time{
h: one Int,
m: one Int,
s: one Int
}
abstract sig Double{
leftPart: one Int,
rightPart: one Int
}
abstract sig Bool{
value: one String
}
sig DateBirth extends Date{}
sig DateRide extends Date{}
sig DateExpiry extends Date{}
abstract sig User {
email: one String,
name: one String,
surname: one String,
gender: one Bool,
address: one String,
password: one String,
dateOfBirth: one DateBirth,
IDRide: set Ride
}
sig TaxiDriver extends User{
taxiLicense: one String,
personalLicense: one String,
IBAN: one String,
positionInQueue: lone Int,
IDTaxi: set Taxi
}
sig Client extends User{
}
sig Zone {
numberOfZone: one Int,
vertexNorthWest: one Double,
vertexNorthEast: one Double,
vertexSouthWest: one Double,
vertexSouthEast: one Double,
currentQueue: set TaxiDriver
}
sig Taxi {
IDTaxi: one String,
plate: one String,
availablePlaces: one Int,
}
sig Ride {
IDRide: one String,
origin: one String,
destination: one String,
dateOfRide: one DateRide,
timeOfDeparture: one Time,
timeOfArrival: one Time,
price: one Double,
numberOfPeople: one Int,
accepted: one Bool,
userEmail: set User
}
sig Credit_Card {
number: Double,
owner: String,
expiryDate: DateExpiry,
ownerEmail: one Client
}
Then, I added the predicate "show" to veify whether the it is consistent or not:
pred Show{}
run Show for 10
After running "Execute" on Alloy Analyzer 4.2 this is the message I get:
Executing "Run Show for 10"
Solver=sat4j Bitwidth=4 MaxSeq=7 SkolemDepth=1 Symmetry=20
21067 vars. 3840 primary vars. 37164 clauses. 376ms.
Instance. found. Predicate is consistent. 375ms.
No problems, right? But then, when I click on "Show" there are no instances of the signature "User" (and its child signatures) shown on the display, while all the others are there. I tried to click on "Next" a gazillion times to try to see if maybe I could find a model in which they were shown, but there weren't any.
Any idea/suggestion? Thanks!
It's probably because of the use of String. As far as I know, String is a reserved word in Alloy, but it is not really implemented at this point. Try to remove the String fields or replace them with something else.
On a more general note, Alloy is not so much about modelling real data (ints, bools and strings), but more about modelling structure, i.e. relationships between entities. For the analysis of structure, you usually don't need concrete data types.
The purpose of building an Alloy model is to capture the essence of a design or system and explore subtle properties. You don't want to include all the details you'd find in a database schema. Your model has lots of implementation details too, such as the ids (which aren't needed since they're implicit in the object identities), and the use of strings instead of conceptual types -- destination, eg, should have a type such as "Location".
So I'd recommend that you start again, and think first about what kinds of questions you'd like this model to answer.
Thanks to everyone, removing strings solved the problem.
However, my "distorted" vision about Alloy's purpose was due to the fact that we were asked to use it but we weren't given a real explanation on how to use it, in most examples all details were written. I guess I'll have to try and study it a bit more!
How do I convert an object of type (NSObject, AnyObject) to the type String?
At the end of the first line of the method below, as String causes the compiler error:
'(NSObject, AnyObject)' is not convertible to 'String'
Casting street to NSString instead of String compiles, but I'm casting street to String because I want to compare it to placemark.name, which has the type String!, not NSString.
I know name and street are optionals, but I'm assuming they're not nil for now because all the places returned from MKLocalSearch seem to have non-nil names and streets.
func formatPlacemark(placemark: CLPlacemark) -> (String, String) {
let street = placemark.addressDictionary["Street"] as String
if placemark.name == street {
// Do something
}
}
A String is not an object, so you do need to cast it to an NSString. I would recommend the following syntax to cast it and unwrap it at the same time. Don't worry about comparing it to a variable of type String! since they are compatible. This will work:
func formatPlacemark(placemark: CLPlacemark) -> (String, String) {
if let street = placemark.addressDictionary["Street"] as? NSString {
if placemark.name == street {
// Do something
}
}
}
This has the added benefits that if "Street" is not a valid key in your dictionary or if the object type is something other than NSString, this will not crash. It just won't enter the block.
If you really want street to be a String you could do this:
if let street:String = placemark.addressDictionary["Street"] as? NSString
but it doesn't buy you anything in this case.
The return type from looking up via subscript for a swift dictionary has to be an optional since there may be no value for the given key.
Therefor you must do:
as String?
I think it may have to do with addressDictionary being an NSDictionary.
If you convert addressDictionary to a Swift dictionary, it should work.
let street = (placemark.addressDictionary as Dictionary<String, String>)["String"]
I think I understand Value Objects ( they have no conceptual identity, set of its attributes is its definition etc) and how they differ from Entities, but I'm still puzzled whether a value of a primitive type ( int, string ...) being assigned directly to property of an Entity is also considered a VO.
For example, in the following code an object ( of type Name ) assigned to Person.Name is a VO, but are values assigned to Person.FirstName, Person.LastName and Person.Age also considered VO?
public class Person
{
public string FirstName = ...
public string LastName = ...
public int Age = ...
public Name Name = ...
...
}
public class Name
{
public string FirstName = ...
public string LastName = ...
public int Age = ...
}
thank you
It doesn't matter if a value is a primitive type (such as string or int) or a complex type composed of primitive types (such as Name). What matters is that you think of it as a mere "value" without any identity -- then it is a value object.
The decision to keep it a primitive or wrap it in a class is an implementation detail. Specific types are easier to extend in the future / add functionality than primitive types.
Check this related question... Value objects are more an implementation thing that a "conceptual" one... If you think about it, singleton and flyweight pattern are about turning an object with an identity to an value object for optimization purposes... It's also related to choosing to implement something as mutable or immutable. You can always say that Person is immutable, but after a while, you are a "new" person with different attributes. It's an implementation decision, not a domain or conceptual one. (Immutable things tend to be value objects, and the mutable ones identity objects).