I have this piece of code:
<a:foo qux="A" xmlns:a="B" xmlns:b="C">
<b:bar a:quux="D" xmlns="E"/>
<xmlns xmlns:a="F" xmlns="G">
<baz a:corge="H" xmlns:baz="I" xmlns=""/>
</xmlns>
</a:foo>
My question is that which namespaces does foo, bar and bas belongs? and which namespaces does the qux, quux and forge belongs?
I think that foo belongs to a and bar belongs to b, but I don't know if that is correct?
Your code sample seems very confusing. Namespaces are a fundamental concept in XML. If you are not familiar with namespaces, please take time to learn and understand them.
Some general notes:
xmlns="something" is a namespace declaration - it is not an attribute,
do not confuse namespace prefixes with namespace URIs, they are separate,
do not confuse namespace prefixes with non-prefixed element or attribute names, they are separate,
elements and also attributes can belong to a namespace,
do not use xmlns as element name,
if you use a prefix, it must be bound to a namespace URI that is within the scope
Answers to your questions are below embedded as comments to your sample code.
<!-- foo belongs to "B", attribute qux has no namespace -->
<a:foo qux="A" xmlns:a="B" xmlns:b="C">
<!-- bar belongs to "C", quux belongs to "B" -->
<b:bar a:quux="D" xmlns="E"/>
<!-- Using element names that begin with xml is against the
XML recommendation. Furthermore, xmlns as element name
does not create a namespace definition -->
<xmlns xmlns:a="F" xmlns="G">
<!-- baz has no namespace, since this element has an empty
default namespace declaration that overrides the one
set the parent element.
corge belongs to "F" because prefix "a" was redefined
in the parent element -->
<baz a:corge="H" xmlns:baz="I" xmlns=""/>
</xmlns>
</a:foo>
Related
A declaration like this one is legal:
julia> function foo end
foo (generic function with 0 methods)
However, besides a placeholder to centralize documentation (and I am not even sure):
module Foo
"""
foo(...) functions
- foo(n::Int) : do something
- foo(n::Int,m::Int) : do other thing
"""
function foo end
I can not see the role/goal of such declaration.
Question: is there an illustrative use case?
The reason is explained in the Julia Manual in Empty generic functions section. There are two main uses:
simplifying documentation or improvement of code readability;
separation of interface definition from implementations.
A typical use case can be seen for definitions of randn! and randexp!. First empty generic functions are defined and are coupled with documentation string. Next methods for those functions are dynamically defined.
Another similar example to study is definition randstring.
Finally look at strides function. It is defined in abstractarray.jl as empty generic function and then used in the same file. But no methods are defined for this function in this file, other files e.g. dense.jl or subarray.jl define such methods.
I have used the setClass function to define several new classes. But these classes don't appear in my Rstudio environment. How do I see all the classes that exist?
Here is an example:
setClass("geckoNss", representation(absolute = "character", item = "list"))
The class now exists somewhere, as we can do
> getClass("geckoNss")
Class "geckoNss" [in ".GlobalEnv"]
Slots:
Name: absolute item
Class: character list
and make objects of that class:
> new("geckoNss")
An object of class "geckoNss"
Slot "absolute":
character(0)
Slot "item":
list()
Yet, I still do not see the class anywhere. BondedDust's answer suggests that you can only see these classes if you assign them to an object.
So is there no way to even see the default classes R comes with?
http://stat.ethz.ch/R-manual/R-devel/library/methods/html/Classes.html
"When a class is defined, an object is stored that contains the information about that class. The object, known as the metadata defining the class, is not stored under the name of the class (to allow programmers to write generating functions of that name), but under a specially constructed name. To examine the class definition, call getClass. The information in the metadata object includes: "
From the setClass help page, it's stored in the environment where it is created (by default) or in the specified with the "where" argument:
"Create a class definition, specifying the representation (the slots) and/or the classes contained in this one (the superclasses), plus other optional details. As a side effect, the class definition is stored in the specified environment. A generator function is returned as the value of setClass(), suitable for creating objects from the class if the class is not virtual."
After running a setClass call at the console you get an object in the global environment by that name:
> track <- setClass("track",
+ slots = c(x="numeric", y="numeric"))
> ls()
[1] "A" "AE_by_factors" "B"
[4] "dat" "dd" "df"
[7] "final" "hl" "len"
[10] "lm0" "ml" "ml0"
[13] "peas2" "realdata" "temp"
[16] "tolerance" "track" "TravelMode"
[19] "vbin" "vint" "vnum"
> track
class generator function for class “track” from package ‘.GlobalEnv’
function (...)
new("track", ...)
> class(track)
#----------
[1] "classGeneratorFunction"
attr(,"package")
[1] "methods"
Your question originally asked about S4 classes, i.e. the ones created with setClass.. It wasn't at all clear that you wanted to find S3 and what might be called default or implicit classes. They are managed in a different manner. If you want to see all the classes that exist for the print function, just type:
methods(print) # I get 397 different methods at the moment. Each one implies an S3 class.
# a variable number of values will appear depending on which packages ar loaded
Also read the help page for ?methods. Those are each dispatched on the basis of the class attribute. For classes, such as 'numeric', integer, character or 'list' that are implicit but not stored in object class-attributes youyou simply need to know that they were built into the original S language. The S3 dispatch mechanism was actually bolted on to that core S mechanism back in the dawn of time. S3 was part of the language when it was described by "New S Language". I currently see that you can still get used copies at Amazon:
New S Language Paperback – June 30, 1988
by R. A. Becker (Author), J. M. Chambers (Author), Allan R Wilks (Author)
There are other functions that allow you to look at the functions accessible along the search path:
> ?objects
> length(objects())
[1] 85
> length(apropos(what="", mode="function"))
[1] 3431
So on my machine a bit more than 10% of the available functions are print methods.
When I import theory files which come with defined constants (for recursive functions or definitions) like f, how can I hide such a constant in the current theory file? In other words, I want to make sure that f is a free variable. I do not want to change the imported files.
That is exactly the purpose of the hide_const command. E.g.,
hide_const f
will completely remove the defined constant f from the current context (and thus make it inaccessible). If you use
hide_const (open) f
instead, only the base name is hidden (i.e., f), but the qualified name (e.g., A.f if f was defined in theory A) still works.
There are similar commands for classes, types, and facts: hide_class, hide_type, and hide_fact. See also the Isabelle/Isar Reference Manual, page 105.
Imagine this scenario:
I have a ZPT in Zope where I define, into a metal block, a global variable.
This variable takes its value from an expression like this
global myVar id | nothing;
global anotherVar 1;
where nothing could be replaced with python:0 or python:False or None and so on.
Now imagine that into another block, I'll do something like
global myVar2 myVar | anotherVar | nothing;
where nothing could be everything that I specified above.
Now suppose that id hasn't a value and so myVar took nothing (or the other possible values; it's makes not difference at all).
What I expected was that myVar2 took anotherVar's value, since anotherVar has a value. But with great surprise, I notice that this isn't true and myVar2 took myVar value; that means nothing.
If I understand what is happening, I'll suppose that this kind of statement only control over existence of that variable and not over it's value.
Obviously I can make that kind of statement into a pythonic way and, of course, it works "well" (namely, as I expected)
So, someone can confirm or disprove what I suppose there ?
What you are asking is not Plone or Zope specific, you are dealing with a TALES statement here, which, together with TAL and METAL form the page template language implemented by Zope Page Templates (and, incidentally, also by chameleon, plus several other implementations in different programming languages).
You are using a TALES path expression when you use the | character, and it is not the same as a Python or expression. Each path named in the expression will by resolved, and only if it doesn't exist will the next path be used. From the specification:
When a TALES path expression is evaluated, it attempts to traverse each path, from left to right, until it succeeds or runs out of paths.
Since all your paths resolve to existing variable names, they all exist and the first one will be used, regardless of it's value.
You want to use a python: expression instead:
myVar2 python:myVar or anotherVar or None;
Note that in TAL there rarely is a need for the global keyword. You probably want to define these items on your root element of your document instead; variables are visible within the same scope as the XML or HTML element they are defined on:
<html tal:define="myVar id | nothing; anotherVar 1;">
<!-- myVar and anotherVar are visible in the whole HTML document -->
</html>
I have a program that draws shapes on an image. I have a separate namespace for each shape, and they are in separate files.
com/name/box.clj --> has com.name.box namespace.
com/name/triangle.clj --> has com.name.triangle namespace.
They all share a common function called generate that draws them on screen, so if I use use, function names clash.
For now, I load them with load-file. Is there a better way of doing this? Looking through the Clojure API, it seems there are multiple ways of including files. Which one is a better option for a project with lots of files?
I too started by using load-file. According to the Clojure documentation on libs,
Clojure defines conventions for naming and structuring libs:
* A lib name is a symbol that will typically contain two or more parts separated by periods.
* A lib's container is a Java resource whose classpath-relative path is derived from the lib name:
o The path is a string
o Periods in the lib name are replaced by slashes in the path
o Hyphens in the lib name are replaced by underscores in the path
o The path ends with ".clj"
* A lib begins with an "ns" form that
o creates the Clojure namespace that shares its name, and
o declares its dependencies on Java classes, Clojure's core facilities, and/or other libs
The Clojure documentation further provides the following example namespace declaration (which I'm sure you already know, but I'm providing it here for completeness):
(ns com.my-company.clojure.examples.my-utils
(:import java.util.Date)
(:use [clojure.contrib.def :only (defvar-)])
(:require [clojure.contrib.shell-out :as shell]))
So, my answer would be to use libs for your project -- it'll help simplify all of those folders. To "include" a lib, you'll use require, like this:
(require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql)
(require '(clojure.contrib def except sql))
As long as the documentation is correct and your project is classpath-relative, everything should happily load. Hope that answers your question. :D
Along with using namespace libs as already has been suggested perhaps your common 'generate' function is a candidate for a multimethod? http://clojure.org/multimethods
This would help avoid the function name clash and add a common abstraction to your 'shapes', I guess it depends on whether an appropriate dispatch function can be found.