[1087] in Coldmud discussion meeting

root meeting help first previous next next in chain last in chain last

[COLD] Re: [ColdCore] Pruning the Object Heirarchy

daemon@ATHENA.MIT.EDU (Wed Sep 18 20:31:01 1996 )

From: silovic@srce.hr (Miroslav Silovic)
In-Reply-To: <199609162122.PAA07984@glacier.cold.org> from Brandon Gillespie at "Sep 16, 96 03:22:45 pm"
To: brandon@glacier.cold.org (Brandon Gillespie)
Date: Thu, 19 Sep 1996 01:55:30 +0200 (MET DST)
Cc: coldstuff@cold.org

> $dictionary_slate         -- still around for reference, somebody record
>                              if they want to keep, does NOT work--out of date

This looks like Webster's dict interface. It'd be VERY nice to have, provided
someone updates it. Not the core object, but we could put it in core_contrib.

> $probe                    -- Jeff artifact, anybody want to examine?

Something like puppet object. Not really useful.

> $mushtoy                  -- Dancer artifact .. ?

Not for the core.

> $ball                     -- Levi artifact

> $help_index_driver        -- urg, what to do?  need to change driver help
> $help_node_driver_...     -- ^^^^ (Miro?)

@edit <helpnode> to edit it. You can change node's index by calling
node.[add|del]_index (or something, check the methods on $help_node.

> $base_realm               -- Miro?
> $levis_realm              -- Levi?

Both are Levi's.

> $user_data2               -- Anybody?  We need to convert $user_data to @set,
>                              I think $user_data2 was an attempt.  Voluteers?
> $jeffs_ui                 -- Jeff artifact, keep anything?
> $actions_ui               -- Jeff artifact, keep anything?

Keep $actions, we'll need it (it seemed to almost work, the last I checked)
No idea what others are.

> $tree_ui                  --\
> $tree                     --\ Jeff Artifacts, what do to with $tree, nix?
> $tree_4                   --/ still used?  $help_node_* used to use it..

@grep for these, I didn't like this code. :) Nothing seems to use it now.

> $help_tree                --/

It doesn't seem used ATM.

> $programmer_interface     -- uhh
> $help_interface_new       -- uhh
> $set_ui                   -- ehrm, how does this work with '@set' on $user?
> $social_interface         -- anybody?  Beuler?

> $editable                 -- \
> $editors                  -- \
> $generic_editor           -- \ Miro, can you list all objects that are involved
> $code_editor              -- / in your editor system, we can nix the derelicts
> $note_editor              -- /
> $editor                   -- /
> $help                     -- void object?  Does this fit in with help anywhere?

$editor_reference, $editor_session, $editor_parser and $editable should be
kept.

> $settings2                -- ?
> $callback                 -- ?
> $message_frob             -- ?


$message_frob is used in message system, right? Dunno other two.

> $climate_taobh_thiar      -- we also need a Creation climate, as Taobh Thiar
>                              Isn't core, and wont exist in a core.

$climate is the parent (and uses $climate_frob).

> $itext                    -- Somebody look at this.. keep/integrate or nix?

It seems useful - something like generic book (but we need to spawn a cross
between this and $thing). It can also be used for generic BBs (for people
who like the 'lookable' mailing lists).

> $hook_notes               -- do we still need?  Who is doing hooks?
> $event_handler            -- Who is doing hooks? convert this with hooks? nix?
> $event_frob               -- ^^^^
> $movement_event           -- /

Peat Young dickered a bit with these. More work is needed.


> $log                      -- I dont know if I like this idea or not.
> $has_reactions            -- I have notes for specs for this somewhere
> $core                     -- what to do?  We shouldn't parent or list
>                              all core objects anymore, just nix this obj?

> $time_root{$time...}      -- need to cleanup this library

Actually rewrite is better idea. We need names for time units to be stored
somewhere, so that $time_<world> can have different names.

> $system_object            -- used to be around for parenting 'system' objects
>                              too, likely can be nixed--I'll grep.

> $world/$control           -- used to focus/control the entire VR and specific
>                              worlds within the VR--have not been written.
>                              Sorta like '$sys' objects for each world.

Thanks for info, I'll need it for weather ticker. Perhaps I'll move the
information what was on $climate to these.

> $ccp                      -- wtf?

Nothing on this object.

> $heart/$scheduler         -- review, I would like to make $scheduler native

$scheduler is outdated and buggy. My suggestion is to use dictionary instead
of heap for event table.

> $read_parser              -- rename/move in heirarchy, its not an official
>                              'parser', it parses from the connection not the
>                              user's parser stack

I'd move this to $login_connection ?

> 
> Then lots of Ctext Stuff:
> 
> $ctext2_frob
> $cml2
> $cml2_evaluator
> $cml2_format
> $cml2_format2
> $cml2_telnet_format2
> $cml2_telnet_format
> $old_cml2_html_format
> $cml2_html_format
> $cml2_base_eval
> $workshop_eval
> $cml2_uncompiler
> $cml2_form
> $cml2_compiler
> $cml_compiler
> $cml_uncompiler
> 
> convert to:
> 
> $j_compiler
> $j_evaluator
> $j_bs_eval
> $j_formatter
> $j_telnet_format
> $j_html_format
> $j_uncompiler

You forgot all the ctext frobs all over the db. We definitely need a grep
that'd work on variables, not just on methods.

> 
> How do (the following) evaluators fit into your ctext Miro?
> 
> $root_evaluator
> $uncompile_evaluator
> $formatting_uncompiler
> $compile_evaluator
> $help_evaluator
> $format_evaluator
> $html_formatter
> $base_evaluator
> $place_evaluator
> $prep_evaluator

This seem to be relics. Leave them for now, I'd like to steal the code.
Not that there seems to be any.