Is there any difference between
EMFEditProperties.list(
editingDomain,
FeaturePath.fromList(DemoPackage.Literals.TRANSPORT_DETAILS__SELECTED_TRANSPORT,
DemoPackage.Literals.TRANSPORT__DEPARTURES))
and
EMFEditProperties
.value(editingDomain, DemoPackage.Literals.TRANSPORT_DETAILS__SELECTED_TRANSPORT)
.list(DemoPackage.Literals.TRANSPORT__DEPARTURES)
?
From studying the sourcecode of EMFEditProperties, I think there is no difference. In fact, if you use a feature path with more than one element, the implementation uses the chained form internally.
Related
Comparing the pages for both methods scan and runningFold (from kotlin.collections), the two appear to be identical save for the name.
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/scan.html
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/running-fold.html
Apparently there is no difference, check this out:
runningFold() and runningReduce() are introduced as synonyms for
scan() and scanReduce(). Such names are more consistent with the
related functions fold() and reduce(). In the future, scan() will be
available along with runningFold() since it’s a commonly known name
for this operation. The experimental scanReduce(), however, will be
deprecated and removed soon.
source: https://blog.jetbrains.com/kotlin/2020/05/1-4-m2-standard-library/
I have been using different forms of Mule's Expression language.
I couldn't figure out the difference between
#[flowVars.myVariable]
and
#[flowVars['myVariable']]
They both give the result when there is a variable. But why do they behave differently when the variable is not present?
Like if the variable being called is not available, then the first expression would result in a exception. Whereas the second expression just gives out a warning or prints out as is, if in a logger message.
Why is this difference?
Also when going through the documentation for Mule 3.6 I found that the second expression is not longer shown in the documentation.
Is the expression #[flowVars['myVariable']] being deprecated?
The difference comes from the way MVEL deals with these two different ways of accessing map entries.
#[flowVars['myVariable']] is equivalent to flowVars.get('myVariable'), which does not fail if the flowVars map does not contain the 'myVariable' entry,
#[flowVars.myVariable] treats the flowVars map as a virtual object, leading to an exception if the 'myVariable' entry is missing because in this case it doesn't resolve to a map get but instead to directly using an object member (either a field or a method), which must exist before being accessed.
I don't think #[flowVars['myVariable']] could be deprecated since it's a core feature provided by MVEL.
Reference: http://mvel.codehaus.org/MVEL+2.0+Property+Navigation#MVEL2.0PropertyNavigation-MapAccess
David has given a nice explanation around your question. To extend that explanation I would just like to add that you can use #[flowVars.?myVariable] to make your code null safe. This is equivalent to #[flowVars['myVariable']].
Regarding #[header:originalFilename], as David said this is not MEL. You can get a list of non-mel expressions which are commonly used in Mule applications in the following link.
http://www.mulesoft.org/documentation/display/current/Non-MEL+Expressions+Configuration+Reference
One example of using the DLR in C# is as follows:
dynamic dyn = new MyObject();
dyn.MyMethod(); //resolved at runtime
what would be the equivalent in F#?
Thanks.
The ? operator has similar expressive power to the dynamic keyword in C# (but it can be only used for reading of properties, method invocation and setting of properties).
There is no built-in implementation that would allow you to dynamically use properties or methods of a .NET class (via Reflection or DLR), but there are some fairly solid implementations from the community. This has been discussed in another SO question before.
There are also implementations of ? that allow you access some common data sources such as SQL databases. For example, this MSDN article includes a definition that allows you to write db?Query?Foo(1) to call a stored procedure named Foo.
For various other types (such as finding an element in XAML or accessing elements or attributes in XML document), the definition of ? is quite easy to write.
On the flip side, if you're trying to expose dynamic behavior to C# from F#, you can use DynamicAttribute[MSDN]. For example, declaring a dynamic property might look like
type HasDynamicProperty() =
[<Dynamic([|true|])>]
member this.DynamicObject : obj = ...
which is used from C# like
var hdp = new HasDynamicProperty();
dynamic dynObj = hdp.DynamicObject;
There's a package called FSharp.Interop.Dynamic and that will make it possible to do a call to a dynamic object using the ? operator.
F# has the ? operator which you use like so:
myVariable?SomePropertyThatIsNotDeclared
There is no dynamic keyword equivalent. Take a look at this article for how to use it https://weblogs.asp.net/podwysocki/using-and-abusing-the-f-dynamic-lookup-operator
I want to find all extensions of org.example.extension.point declared in com.example.plugin. Is there a more efficient way to do so than doing
List<IConfigurationElement> result = new ArrayList<IConfigurationElement>();
IConfigurationElement[] allConfigElements =
Platform.getExtensionRegistry.getConfigurationElementsFor("org.example.extension.point");
for (IConfigurationElement ice : allConfigElements) {
if (ice.getDeclaringExtension().getNamespaceIdentifier() == "com.example.plugin")
result.add(ice);
}
return result;
?
No there are no other (more efficient) ways (is this not simple enough?;). In addition I'd use ice.getContributor().getName() instead of ice.getDeclaringExtension().getNamespaceIdentifier()
I really would like to know why you want to filter by a specific contributor. - I mean if you have to "know" the contributor why are you using the extension point? The main purpose of an extension point is using inversion of control; the main characteristic of using extension points is not knowing the contributor. No offense, but probably you are using extension points in a way they are not intended for...
This question is a little silly, but sometimes it's tough to figure out how to name things correctly. The conversion will parse a config file into XML and vice versa. I want to call the program MyCompany.Config2Xml, but the program also needs to be able to "Xml2Config".
I propose: ConfigParser
In keeping with SqlDataReader, TextReader, XmlReader etc I'd just call it ConfigReader and ConfigWriter.
Or, you could just go the serialization approach and then not have to worry about naming conventions.
CC for short:
ConfigConverter ?
Rather than ConfigParser as proposed by jeffamaphone (+1 for nice username), make it a verb:
parse-config
This makes it read nicely in scripts:
if ! parse-config < config-file > config.xml; then
exit 1
fi
I think it helps a lot to think about the verbs (methods) you intend to use with the class and the role the class plays in the application.
In other words if you envision the operation to be {class}.Get() or {class}.Load() then ConfigParser might be a good choice.
If on the other hand you have a corresponding {Class}.Set() or {class}.Save() operation then something like ConfigManager would be a better choice, particularly if the class will be used to isolate the application from the persistence of its configuration.
If the role of the class is nothing more than part of a standalone application or a step in a longer running process then I would would lean more towards class and method pairs that are more like Convert.ToXml() Convert.ToConfig() or Translate.FromXml() Translate.FromConfig().
General term seems like it would be format convertor, or transformatter (by analogy with transcoder). In terms of the specific names you discuss, I think I'd go with ConfigConvertor.
DaTransmogrifier
UberConvertPlus
Xml2Config2Xml
ConfiguratorX
'XConTrans'
or simply 'Via'
ConfXmlSwitcher :P