What is the uses for in the .Net code


(Theo (will be on a dushi island)) #1

A beginners question.

In Pascal we have uses - where the pas files that are referenced are maintained.
But in .Net, the project has it’s references in the project.
So what is the uses used for in Oxygen in .Net?

(Carlo Kok) #2

It’s used to bring namespaces in scope. Without a uses you would have to type the full name of a type: var x: System.Collections.Generic.List<string>


Uses System.Collections.Generic;
var x: List<string>

(Jolyon Direnko-Smith) #3

And perhaps worth mentioning here is that this is exactly equivalent to a using statement in C#. The only difference being the comma separated nature of the namespaces in a uses statement, rather than a litany of individual using statements.

(marc hoffman) #4

I also recommend checking out https://docs.elementscompiler.com/Oxygene/Delphi/NamespacesAndReferences/ (and https://docs.elementscompiler.com/Oxygene/Delphi/ in general).

(Theo (will be on a dushi island)) #5

That is what I thought, but it seems it doesn’t work:

(Carlo Kok) #6

Uses can’t be used for relative namespaces. ie

var x := new Dictionary< ....>;

is perfectly fine, but above case doesn’t since “generics” is the namespace this type is in.

(Theo (will be on a dushi island)) #7

Ok, clear - it only imports the types within a namespace, not the namespaces itself (correct?)
( in Vb.net it also imports the namespaces, so my example works in VB.Net).

(marc hoffman) #8

Basically, having a namespace in the uses clause just brings all types (and other elements, such as global methods) “into scope”, so that they can be referenced without having to prefix them with their full name.

(Jolyon Direnko-Smith) #9

All of the twoddle below was a complete red herring caused by the fact that the default Project Imports bring all of these involved namespaces in automatically, irrespective of any explicit imports statement in a module in that project.

Yeah, the VB.NET `Imports` statement is a dogs breakfast (imho). It not only imports any qualified namespace but also all referenced _parent_ namespaces **and** any _child_ namespaces:
Imports System.Collections.Generic

Is seemingly equivalent to:

Imports System

Waaaah!? :dizzy_face:

There is no direct equivalent in Oxygene except to list all namespaces at all levels within the System namespace. It is not simply equivalent to:


However, the above Oxygene is equivalent to the C#:

using System;
using System.Collections;
using System.Collections.Generic;

i.e. VB.NET is a mess all to itself, not a .NET-ism.

Whilst the VB.NET approach might seem like a great convenience feature, if you do want all of those namespaces imported (but don’t forget, it also brings in a bunch of stuff you perhaps had no idea even existed), what this means if you don’t is that it is impossible to import just the Generic namespace without polluting your scope with everything in System and System.Collection as well.

In other words, in VB.NET I don’t think there is any way to do this:


i.e. bring that specific namespace into scope without also dragging in all parent and child namespaces.

A simple, but illustrative example:

Imports System.Collections.Generic.Dictionary(Of String, Integer)

Module Module1

    Sub Main()
        Dim d As Dictionary(Of String, String)
        Dim c As Hashtable
    End Sub

End Module

First, we’ve specifically and implicitly imported a specific specialised Generic.Dictionary (you have to provide type params, you cannot import the generic itself).

But, as you can see, we can then simply reference and (specialise differently) a Dictionary<T, V> (from the Generic namespace) and Hashtable (from the Collections namespace) without qualification.

This is because to ‘reach’ the Dictionary type in the Imports we had to reference System, Collections and Generic and in so doing we drag aaalll those namespaces in.

And after all that, we might just as well have simply said Import System and achieved the same result.

(marc hoffman) #10

C# is even worse., because this breaks:

namespace RemObjects.Elments.Foo;

var x: System.String;

Wanna know why? because there’s a RemObjects.Elements.System namespace, and just by virtue of the code I’m writing living underneath RemObjects.Elements, that system gets precedence over there root System. f’ing insane — but that’s the rules. :wink: (at least C# has global:: to override it ;))

Oxygene can do


though, which is awesome.

Now, don’t get me started about Java and imports :stuck_out_tongue_winking_eye:

(Theo (will be on a dushi island)) #11

What you describe is caused by the project namespace imports, where the standard (with the project template referenced dll’s) are already imported at project level.

(Jolyon Direnko-Smith) #12

Yikes, you’re quite right. Ok, so the namespace imports isn’t as dumb as this made it appear, but even the idea of project imports is itself dumb (imho).

(marc hoffman) #13

Isn’t that (in concept, ignoring how VB handles the specific) the same as Default Uses in Elements? if so, I find those super useful. Especially for cross-platform shared code.

(Theo (will be on a dushi island)) #14

I like them - and used them a lot for my standard libraries; I have some libraries I need for almost any project (my own framework), so I reference them and import them on project level.

Did not know yet that this was available in Oxygene too.
Where can I find those?

(Carlo Kok) #15

Default uses in the project options.

(Theo (will be on a dushi island)) #16

Found it - thanks.