aNewList = []
s = StringScanner.new sNewList
upper = /[A-Z]+/
not_upper= Regexp.new(  upper.source.sub( /\[/, '[^' )  )
while not s.eos?
  case
     when s.skip(upper); aNewList << s.matched
     else s.skip(not_upper)
  end
end

But the not_upper Regexp definition is really a kludge.  It somewhat
camouflages what is really /[^A-Z]+/

I'd like to DRY it by expressing it as something like !upper.  I need
something like !~ we use normally with string searches.

  a_new_list = s_new_list.scan(/[A-Z]+/)

Note that I've also switched your variable naming style to the snake_case that we Rubyists prefer.

Hope that helps.

aNewList = []
s = StringScanner.new sNewList
upper = /[A-Z]+/
aNewList<< s.matched while s.skip_until(upper)

But cutting out 90% of the code, wow!  That's DRY!!

Thank you very much for your ideas.  I haven't tested it yet, but it
looks right to me.

As I said to Caleb, cutting my 10-liner down to 1 is extreme DRYing!!
Thanks for that.

As far as underscoring vs. Camel-case goes,  I know Rubyists'
preference, but I bow to Shakespeare's notion that "a rose by any
other name is just as sweet."  I spent a couple decades writing/
maintaining Window's application for clients using C and C++, so I've
a fondness for Polish notation (at least that's what I think it was
called.) Typing extra hyphens vs pressing the shift key lets me write
code faster, and the a/s/h prefix for arrays/strings/hashes helps me
avoid a lot of interpreter complaints.  And fellow programmers of
almost any stripe knows what I mean.  Finally,  I retired curmudgeon,
and you know how we old folks are :-)

Seriously,  your insight was very helpful and will help me avoid a
bunch of wasteful code.

With your insights,  I was able to cut down 18 lines of somewhat
obscure code to 6 lines that I find very readable.  That's such and
improvement on the quality of the code.

Though I expect you guys are tired ot this thread, I included the new
and old code below, along with results that both of them produce.

Again,  thank you very much for your insights.

Best wishes,
Richard

# Accept a new list as a string; extract an array of contiguous upper-
case letters as stock symbols, ignoring any duplicates (Test data)
# Delete any symbol in the current list that occurs here
sNewList = %{TMxxx CSCO COL INTC BRCM FDX AA CAT BUR FSLR MSFT',
                      PNC HPQ CSCO AMAT ORCL FCX ABX PVTB XHB CSCO TM FDX}

#===============
# New technique
#===============
aRawNewList = sNewList.scan(/[A-Z]+/)
aNewList = Set.new(aRawNewList ).to_a.sort
nDeleted = 0
aNewList.each { |sym| hCurrentList.delete sym and nDeleted += 1  if
hCurrentList[sym] }
show_array( aNewList, 10, "New List (unique:%d, dups:%d, deleted:%s)"
%
  [aNewList.size, aRawNewList.size - aNewList.size, nDeleted] , true)

#============================
# Old technique; No longer used
#============================
aNewList = []
s = StringScanner.new sNewList
upper = /[A-Z]+/
non_upper= Regexp.new(  upper.source.sub( /\[/, '[^' )  )
nNewSyms = nCurrSymsDeleted = 0
while not s.eos?
  case
    when s.skip(upper)
      nNewSyms+=1
      aNewList << s.matched unless aNewList.include? s.matched
      ( hCurrentList.delete s.matched and  nCurrSymsDeleted += 1)  if
          hCurrentList[s.matched]
     else
       s.skip(non_upper)
  end
end
show_array( aNewList.sort, 10, "New List (%d unique; %d dups; %d curr.
deleted)" %
  [aNewList.size, nNewSyms - aNewList.size, nCurrSymsDeleted] )

Side note: with modern IDE's I believe there is not much reason to use
Hungarian Notation any more.  I personally find it more difficult to
spot certain variables when all variables of the same type start with
the same letter.  For me, PN actually _reduces_ readability.

Cheers

robert

  sNewList = %{TMxxx CSCO COL INTC BRCM FDX AA CAT BUR FSLR MSFT',
               PNC HPQ CSCO AMAT ORCL FCX ABX PVTB XHB CSCO TM FDX}
  aRawNewList = sNewList.scan(/[A-Z]+/)
  aNewList = Set.new(aRawNewList ).to_a.sort

can be replaced by one:

  aNewList = %W{TMxxx CSCO COL INTC BRCM FDX AA CAT BUR FSLR MSFT',
                PNC HPQ CSCO AMAT ORCL FCX ABX PVTB XHB CSCO TM FDX}

(you can add .sort to the end but I don't think you need it)

also, consider something like this:

  hCurrentList.delete_if { |key,v| aNewList.include?key }

Here's my suggestion

require 'set'

# dumy base
current = {"CSCO" => 1, "COL" => 2, "INTC" => 3, "BRCM" => 4, "FOO" => 99}

# user input
input = %{TMxxx CSCO COL INTC BRCM FDX AA CAT BUR FSLR MSFT
  PNC HPQ CSCO AMAT ORCL FCX ABX PVTB XHB CSCO TM FDX}

# algorithm
symbols = input.scan(/[A-Z]+/)
deduped = symbols.to_set

old_size = current.size
deduped.each {|sym| current.delete sym}

p(deduped.sort,
  10,
  sprintf("New List (unique:%d, dups:%d, deleted:%s)",
    deduped.size,
    symbols.size - deduped.size,
    old_size - current.size),
  true)

p current

Cheers

robert

I spent a couple decades writing/

But in any case, *you've been had*.  Hungarian Notation as developed by
Charles Simonyi is extremely useful in non-OO code (I've used it in PHP
with great success).  Hungarian Notation as the term is usually
understood is a very stupid thing indeed, which has unfortunately been
foisted by Microsoft on huge numbers of Windows programmers who really
should know better. :)  It is (at best) marginally useful in statically
typed languages like C, and downright misleading in dynamically typed
languages like Ruby.

The difference is that Simonyi's original concept encodes information
*outside the scope* of the variable's type (which, after all, the
interpreter or compiler already knows about).  For example, in a mapping
system, you might have kmDistance and ftCorrection.  It's entirely clear
from those names that kmDistance + ftCorrection would be adding
kilometers and feet without a conversion, and thus it's immediately
clear that that operation is wrong.

OTOH, legions of misled Windows developers would simply call those two
variables intDistance and intCorrection, incorporating no new useful
information and making the names harder to read.

For more on the misuse of Hungarian Notation, please see
http://www.joelonsoftware.com/articles/Wrong.html (Simonyi's original is
there called Apps Hungarian, while the popular perversion is called
Systems Hungarian).  There's also some interesting discussion at
http://c2.com/cgi/wiki?HungarianNotation , if you can wade through the
disorganization.

Systems Hungarian, BTW, is bad enough in C, where you should be able to
refer to your variable declarations.  If your functions are so long that
you can't refer easily to declarations, then you need to refactor to
shorter methods for overall readability anyway -- methods should be
short.  Systems Hungarian has no use at all in Ruby, since although
objects are typed, variables are not, so it's perfectly possible to do
intValue = 1
# later
intValue = {:foo => 'bar'}

Even Apps Hungarian is not a great idea in OO code.  Instead, just use
the type system, so that distance would be a Kilometer object and
correction would be a Foot object.  Kilometer.+(foot) could then either
raise an exception or invoke a conversion.

In summary, then, Hungarian Notation of either sort is inappropriate in
Ruby.  Drop the habit.

In any case, "snake_case" is the prevailing style in Ruby, and virtually
every Ruby library uses it (including the standard library and Rails) --
your code will look strange if you don't follow suit.  The examples in
Programming Ruby tend to use camelCase, but that's more of a flaw in the
book than an indicator of Ruby practice.

As a vim user, with very limited interactive debugging, my primary  
exploration technique will usually consist of at most a couple of  
'obj.methods.grep' calls followed by grepping ~/gems which seems to  
emphasize the actual reading of the source for object identity info.

Python's integrated documentation would be really welcome in this  
case, i think. :)

I'm curious what you think the most correct way is to discover object  
identity.

From: "David Turnbull" <dsturnb...@gmail.com>

  def foo(bar)
    if bar.is_a? Array
      do_array_thing(bar)
    elsif bar.is_a? String
      do_string_thing(bar)
    else
      ... # ?
    end
  end

I believe it's (variations on) the above that are viewed
as unreasonably restrictive in ruby.

It's challenging, too, because even :respond_to? can be
misleading.

I like Og (Object Graph), an Object Relational Mapping
library in ruby providing high-level database access.

  require 'og'

  class Address
    property :name, String
    property :company, String
    property :dept, String
    property :addr1, String
    property :addr2, String
    property :city, String
    property :state, String
    property :zip, String
    property :country, String
    belongs_to :order, Order
  end

When Og is initialized, it searches ObjectSpace for
classes like the above, and detects that they are
intended to be Og-managed classes, and imbues them
with certain basic features.  (It also generates the
SQL needed to create the database tables
corresponding to such classes.)

An example is that, given nothing more than the above
Address class declaration... I could now say:

  result = Address.find_by_name_and_state("Bob Jones", "CA")

But..! The Address.find_by_name_and_state doesn't even
exist until the time that it is called.  Part of the
magic with which an Og-managed class is imbued, is
some method_missing logic which looks for particular
method signatures, like /find_by_(.*)/ , and, at the
moment such a method is called, is tested against the
following, behind the scenes:

  def method_missing(sym, *args, &block)
    if match = /find_(all_by|by)_([_a-zA-Z]\w*)/.match(sym.to_s)
      return find_by_(match, args, &block)
    elsif match = /find_or_create_by_([_a-zA-Z]\w*)/.match(sym.to_s)
      return find_or_create_by_(match, args, &block)
    else
      super
    end
  end

(Note: In this case, it appears Og _always_ handles the
request via method_missing.  But I've seen other code
in Og (or maybe Nitro) that did *define* the method when
it was first called, such that on subsequent invocations
the method would now already be existing.)

. . . Anyway, the point being, Ruby is pretty dynamic.

:)

Regards,

As a newbie I would surely like to know why the language decided on
"elsif" rather than "elseif".

And before anyone accuses me of not doing a Google search on the
subject ... I did.  E.g. http://www.ruby-forum.com/topic/100350

I'm not trying to change the language ... I'm wondering if the
language developer(s) had a reason for it?  Did the want to save the
typing of an 'e'?

- - - -

While we're at it, is there a (undocumented?) compiler switch that says "always check
for then in if/elsif statements"?

http://talklikeaduck.denhaven2.com/files/TypesFromTheClientsViewpoint...

IMHO, viewing a variable as a 'role' to be filled with one or more
objects is a powerful technique.

Alastair Cockburn recently told me that he still refers clients to the
reference paper, which I wrote at IBM, when he and l were both there.

The view fits into a general approach to OO design which is called
"responsibility based" or "role based" design.  Rebecca Wirfs-Brock
was one of the authors who published books on the approach

http://www.amazon.com/Rebecca-Wirfs-Brock/e/B001IQXNWC/ref=ntt_athr_d...

This was before the static-typing crowd (starting with C++) took over
the conventional wisdom as to what it meant to be OO, in turn leading
to a proliferation of "methodologies" using static typing.

Those of us in the dynamic typing/roles/responsibility based community
see this as an unfortunate parallel to Gresham's Law.

With the re-birth of interest in dynamically typed languages I think
that the role based view is preferable.

--
Rick DeNatale

http://github.com/rails/rails/blob/master/activerecord/lib/active_rec...

  def ri(*names)
    system(%{ri #{names.join(" ")}})
  end

  http://lsrc2009.confreaks.com/

I can give a couple of examples.

I recently ran across some code that had extensions to a core system.  Each extension would reopen the core classes and edit away.  Unfortunately, they had to duplicate a lot of the core code to make little changes to it.  I rewrote the code to allow extensions to register modules with the core classes.  Then when those classes produced objects, they would mix in any registered modules.  This simple eliminated almost all of the duplication, because the modules were in the singleton class *in front of* the methods they were modifying.  They could read the arguments and see if they needed to step in with their modified behavior, or just hand off to super().

I showed another example in my talk where I was trying to create a one instance configuration object.  Originally I did it with a constant and some clever reopening of the singleton class, but that caused problems like not being able to easily document this object's API.  I switched to just creating the one instance I needed and immediately mixing in a module that added the special functionality and it solved all the problems I had.  You can document a module just fine.  (The example is in my slides, if you want to see it:  http://blog.grayproductions.net/articles/lone_star_rubyconf_slides.)

I think we should do more of this.  For example, I think we could return an Array that mixes in a Paginated module instead of a PaginatedCollection object that inherits from Array.  That feels more right to me.  It's an Array and it has some extra functionality added in related to pagination. The uses go on and on.

This kind of thing:

   class String
     def method_I_need_once_or_twice
     ...

is almost always overkill. It's sort of the core-functionality
counterpart of using global variables. Extending an object is a much
more precise operation -- and has the additional merit, I find, of
really making you think about whether it's worth bothering to the
extend the object instead of working with what the object can already
do.

David

--
The          Ruby training with D. Black, G. Brown, J.McAnally
Compleat     Jan 22-23, 2010, Tampa, FL
Rubyist      http://www.thecompleatrubyist.com