Src view vs Module View - just for interests sake

Hi All,

This time not a question, but I thought I'd show what a source view looks like with its comparable module view beside it. The module view still retains the original collection of orphans that we both love and hate. Organizing your object into packages will only show within the context of your source view, but perhaps that's all that is required for team development as no one is supposed to be touching the ospace once it's on the server.

Anyway, here's the slide. It's my hope that seeing things in both perspective will demystify packages a bit

-Hugh

Find more posts tagged with

Comments

Chris Meyer

Quoted Hugh Ferguson on 05/28/2014 08:56 AM:

Anyway, here's the slide. It's my hope that seeing things in both perspective will demystify packages a bit

I wish this were true. Perhaps I'm too familiar with Builder to make sense of the OScript Explorer perspective, but I'd be interested to know what a newcomer to OScript will make of this. I definitely see the connection between the perspectives, but it's very confusing when switching between them!

HFCDev

It was useful showing this (for me anyway) to ensure that when I created a child object, it really was a child object and shows up in the module (old-school) view where I'd expect it.

Now here is where it gets confusing. The package objects allow for a new way of referencing the object. Whereas before I would call methods in my Utils object (the child off of $Module Root) by $ModuleName.Utils.Functionname, if I create a child Utils of my $ModuleRoot (and yes, OT, I know these are global variables only available at run-time), and I create a package called Utils, the reference is not MODULENAME::Utils.Functionname but MODULENAME::Utils::Utils.FunctionName. That is the path to any child object you create of your root object is

MODULENAME::Pkg path::ChildObjectName.FunctionName.

So for old-school oscripters, it means if you have a bunch of utils type objects under your root object, you probably shouldn't bother packaging them, or simply make their package the module name (when you create the child). Obviously if you have a module built in CS 10.0 or earlier, this will be done for you. I will by trying out the import function later today. The past few days have been about creating modules for 10.5 from scratch.

-Hugh